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PREFACE 


This  technical  report  is  the  final  report  documenting  the  results 
of  a two  year  effort  at  Case  Western  Reserve  University.  This  effort 
produced  a mathematical  model  of  security  in  computer  systems.  The  mod- 
el mathematically  represents  the  Department  of  Defense  Information  Se- 
curity Program  and  establishes  sufficient  criteria  for  security  controls 
to  prohibit  the  unauthorized  disclosure  of  information  contained  in  com- 
puter systems. 

The  modeling  effort  provides  the  technical  foundation  for  the  multi  - 
facited  Automatic  Data  Processing  (ADP)  Security  Program  sponsored  by  the 
Air  Force's  Electronic  Systems  Division.  The  model  guided  the  implemen- 
tation of  security  enhancements  for  a now  operational  Air  Force  computer 
system,  the  Honeywell  Multics  system  at  the  Air  Force  Data  Services  Cen- 
ter. Use  of  this  system  to  process  information  of  multiple  classifica- 
tions requires  operation  of  the  system  in  a "non-malicious"  environment 
because  the  controls  were  not  analytically  proven  to  be  totally  effec- 
tive. A separate,  on-going  phase  of  the  Security  Program  has  the  goal 
of  developing  a secure  general  purpose  prototype  computer  system  with 
security  controls  which  are  similar  to  those  of  the  operational  system 
but  which  have  been  proven  effective  a priori.  The  security  of  the 
prototype  system  will  be  proven  by  demonstrating  the  correspondence  of 
the  implementation  (through  a series  of  intermediate  design  representa- 
tions) to  the  model. 
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1.  INTRODUCTION 

1 . 1 Motivation 


The  Air  Force,  as  well  as  many  other  government  agencies,  have 
already  accumulated  a great  deal  of  national  security  as  well  as  other 
sensitive  information  in  computer  systems  throughout  the  world.  It  is 
likely  that  the  use  of  computerized  systems  for  information  storage 
and  retrieval  will  become  even  more  pervasive  in  the  near  future.  Pro- 
tecting this  computerized  information  from  unauthorized  disclosure  is 
a problem  because  traditional  security  measures  are  not  always  direct- 
ly applicable  to  computer  systems.  In  fact,  dealing  with  this  new  en- 
vironment necessitates  a reexamination  of  the  purposes  of  the  Department 
of  Defense  Information  Security  Program  governing  classified  information. 

Dedicating  a separate  computer  facility  to  a particular  classifi- 
cation of  information  would  solve  many  security  problems  in  Air  Force 
applications.  However,  it  is  more  feasible  as  well  as  financially  pre- 
ferable to  combine  a number  of  small  computer  installations  into  a 
single  large  installation.  Unfortunately,  current  computer  operating 
systems  lack  sufficient  certifiable  correctness  of  design  needed 
to  provide  sophisticated  security  to  their  users.  This  lack  of  provable 
soundness  would*  even  concern  small  installations  where  it  would  be  de- 
sirable to  enforce  "need- to- know"  restrictions  on  the  dissemation 
of  information. 

In  addition,  there  are  operational  requirements  in  the  military 
which  necessitate  the  sharing  of  large  computer  data  bases  among  many 
subgroups.  This  sharing  is  used  to  promote  coordinated  and  efficient 


1 


operation  of  a computer  system  as  well  as  reduce  the  cost  of  maintenance 
and  other  system  overhead. 


1.2  The  Mu 1 tics  System 

Multics  is  a sophisticated  time-sharing  system  with  a large  shared 
file  data  base.  This  system  was  developed  at  Massachusetts  Institute 
of  Technology  in  cooperation  with  Bell  Labs  and  General  Electric  and 
is  currently  supported  by  Honeywell  on  a 68/80  machine.  Multics  has 
evolved  with  several  features  which  are  of  interest  from  a security 
point  of  view.  For  example,  the  access  control  lists  on  the  user  files 
certainly  appear  sufficient  for  the  military's  "need-to-know"  security 
requirements. 

The  68/80  hardware  also  provides  several  protection  mechanisms 
which  keep  the  run-time  cost  for  security  checking  from  being  prohibi- 
tively high.  The  access  control  bits  on  each  entry  in  the  segment  ta- 
ble of  a process  allow  selective  access  restrictions  to  be  enforced 
on  each  instruction  execution.  The  eight  protection  rings  of  Multics 
provide  nested  domains  which  can  be  used  to  separate  the  security  sy- 
stem and  more  vital  portions  of  the  operating  system  from  users  as  well 
as  the  remaining  less  reliable  parts  of  the  operating  system. 
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1.3  The  General  Goal 


The  overall  objective  of  the  current  Air  Force  project,  of  which 
we  are  a part,  is  to  develop  a certifiably  secure  computer  system  using 
a Mul tics-like  machine  thereby  providing  the  Air  Force  with  a useful 
as  well  as  secure  system.  In  the  process  it  is  important  to  develop 
design  techniques  which  can  be  used  in  developing  secure  operating 
systems  for  other  machines  and  other  applications.  Arriving  at  a pre- 
cise definition  of  Computer  Security  for  military  purposes  is  a parti- 
cularly significant  part  of  this  second  goal.  The  design  technique 
used  in  this  effort  should  ultimately  lead  not  only  to  a system  which 
is  secure,  but  also  to  a system  which  can  be  proven  secure. 
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1.4  The  Proposed  Approach 


Because  of  its  enormous  size  and  complexity,  it  is  difficult  and 
tedious  to  analyze  an  operating  system  while  considering  it  as  a whole. 
Fortunately,  however,  it  has  proven  feasible  to  isolate  the  security 
related  portions  of  an  operating  system  in  a comparitively  small  soft- 
ware module  which  we  call  a Security  Kernel.  In  essence,  the  security 
kernel  will  consist  of  the  elements  of  an  operating  system  needed  to 
verify  and  monitor  the  transfer  of  information  around  the  system.  Pro- 
tection hardware  will  be  used  to  completely  isolate  the  security  kernel 
from  external  programs.  The  implementation  of  this  security  kernel 
will  provide  the  user  with  a virtual  machine  which  will  have  somewhat 
different  memory,  10  control,  and  instruction  set  than  those  provided 
by  the  bare  hardware  of  the  68/80.  (E.g.  the  virtual  machine  will  not 

appear  to  have  a disk  memory,  but  rather  a "directory  structured"  me- 
mory.) This  virtual  machine  is  referred  to  as  the  Security  System. 

To  facilitate  certifying  the  correctness  of  the  security  kernel 

it  must  be  kept  as  small  as  possible.  However,  all  security  related 
aspects  of  the  entire  system  must  be  considered  in  the  design  of  the 
security  kernel.  Accordingly,  the  current  Multics  operating  system 
must  be  very  carefully  disected  to  determine  the  portions  which  must 
go  inside  the  security  kernel  and  those  which  can  remain  outside  in 
the  residual  operating  system. 

Our  task  then,  is  to  develop  a sound  set  of  specifications  for 
the  security  kernel.  These  specifications  should  take  into  account 
the  security  features  of  the  hardware  which  will  be  available  to  the 
actual  implementors  of  the  security  kernel. 
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1.5  A Short  History  of  Work  in  the  Area 


In  1969  Butler  Lampson  [7]  presented  an  abstract  framework 
within  which  to  discuss  computer  security.  He  identified  and  described 
the  concepts  of  subjects  and  objects  as  the  active  and  passive  elements 
in  a computer  system.  His  subjects  and  objects  were  used  as  prototypes 
for  our  work  and  correspond  roughly  to  our  agents  and  repositories. 

The  privileges  of  the  subjects  to  manipulate  objects  was  determined  by 
an  access  matrix  which  was  maintained  by  the  security  system. 

Weissman,  in  a subsequent  effort,  attempted  to  apply  governmental 
security  restrictions  to  a computer  system  in  his  Adept  50  system 
[ 16  1 . The  Adept  50  system  was  an  operating  system  designed  for 

an  IBM  360  model  50  which  included  some  features  of  governmental  security. 

In  1971,  the  Air  Force  Electronic  Systems  Division  formed  a se- 
curity panel  to  discuss  Air  Force  needs  and  responsibilities  in  the 
area  of  computer  security.  Anderson  [ 2 ] reported  the  conclu- 
sions of  this  panel.  Two  of  the  recommendations  of  this  panel  are  of 
particular  significance  to  the  current  project.  First,  the  panel  con- 
cluded that  the  Air  Force  should  invest  in  an  effort  to  develop  secure 
operating  systems.  Secondly,  the  panel  recommended  that  such  an  ef- 
fort should  begin  by  developing  sound  mathematical  models  of  the  de- 
sired system.  The  research  reported  in  this  paper  represents  a portion 
of  this  modeling  effort. 

In  1973,  Schell,  Downey,  and  Popek  [ 12  ] articulated  their 

preliminary  views  on  how  the  mathematical  models  of  a security  system 
should  be  formulated.  Bell  and  LaPadula  [ 4 ] followed  up  these 
preliminary  views  with  considerably  more  elaborate  versions  of  the 
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proposed  mathematical  models. 

Our  efforts  on  this  project  began  in  the  spring  of  1973.  We 
soon  discovered  certain  necessary  security  requirements  of  the  system. 
We  realized  that  a major  component  of  the  problem  was  to  develop  a 
language  in  which  to  discuss  the  solution.  We  found  that  this  langu- 
age was  necessary  both  to  describe  the  desired  system  and  eventually 
to  carry  out  the  proofs  that  the  implementation  was  correct.  We  quick- 
ly found  that  discussing  the  rationale  behind  certain  design  decisions 
necessitated  the  use  of  certain  auxiliary  concepts  which  would  have  no 
specific  realization  in  the  final  implementation. 

Our  first  attempts  resulted  in  a rough  model  corresponding  approxi 
mately  to  the  present  S2  specification  in  this  paper.  In  formulating 
this  model,  we  discovered  two  design  principles  which  evolved  into  the 
acquisition  and  dissemination  axioms  of  the  SQ  specification.  We 
developed  Sq  to  emphasize  the  importance  of  these  principles  and  to  for 
mulate  a firm  foundation  for  future  development.  We  then  developed 
the  S.j  specification  to  discuss  tree  structured  file  systems  and  to 
explain  our  somewhat  surprising  conclusion  that  the  classification  of 
files  must  not  decrease  as  you  progress  away  from  the  root  of  the  tree. 
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1.6  Structured  Specification 


One  of  the  more  important  results  of  our  work  has  been  the  develop- 
ment of  a design  technique  which  we  call  structured  specification.  In 
brief,  this  technique  consists  of  systematically  developing  detailed 
specifications  from  an  initial  general  specification  by  introducing  addi- 
tional system  details  through  a sequence  of  refinement  steps. 

This  technique  has  the  advantages  of  allowing  system  analysis  to 
take  place  in  an  environment  less  cluttered  with  irrelevant  system  de- 
tails, as  well  as  allowing  large  problems  to  be  broken  into  smaller, 
more  tractable  tasks.  In  addition,  structured  specification  encourages 
the  discovery  of  similarities  between  different  parts  of  the  system 
and  of  system  wide  principles. 

The  structured  specification  technique  initially  involves  formu- 
lating a simple  specification  for  the  system  (in  this  paper  Sq).  Next, 
a more  detailed  level  of  specification,  usually  having  somewhat  dif- 
ferent sets,  functions,  and  relations,  is  created.  It  must  then  be 
established  that  the  new  specification  is  simply  a refinement  of  the 
previous  specification.  This  is  accomplished  by  identifying  the  old 
sets,  functions  and  relations  within  the  new  specification  and  then 
proving  that  the  axioms  of  the  old  specification  are  consequences  of 
the  axioms  in  the  new  specification.  This  process  of  creating  and 
proving  levels  of  specification  continues  until  the  newest  specifica- 
tion can  be  implemented  in  software  on  the  hardware  of  the  available 
computer. 

The  axioms  of  the  final  level  of  specification  constitute  the 
assertions  which  must  be  proved  about  the  implementation  in  order  to 


7 


establish  that  it  is  "correct".  Since  each  level  of  specification 
has  been  proven  to  be  a refinement  of  its  predecessor,  the  final 
implementation  will  be  accurately  described  by  each  level  of  specifi- 
cation (in  particular,  the  first  level,  Sq). 
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1.7  An  Outline  of  the  Report 


The  second  through  fifth  chapters  of  this  report  have  been  organized 
in  accordance  with  the  structured  specification  methodology  discussed 
previously.  Chapter  two  is  devoted  to  the  Sg  specification  which  con- 
stitutes our  basic  definition  of  an  uncompromi sable  computer  system. 

Chapter  three  discusses  the  S-j  level  of  specification  which  intro- 
duces the  concepts  of  mailboxes  for  interprocess  communication  and 
directories  for  file  system  organization.  The  S2  level  of  specification 
discussed  in  the  fourth  chapter  of  this  report,  introduces  some  of  the 
dynamic  aspects  of  the  security  system.  The  S2  specification  abstractly 
describes  the  manner  in  which  the  access  control  bits  in  the  Multics 
segment  descriptor  tables  are  to  be  used  to  enforce  security.  This 
chapter  also  contains  a discussion  of  the  relation  between  "dynamic" 
and  "static"  models  of  security. 

The  fifth  chapter  presents  the  Sg  specification  which  gives  a 
considerably  more  detailed  account  of  the  proper  handling  of  the  file 
and  process  attributes.  It  includes  an  extensive  list  of  security 
system  commands  which  must  be  developed  when  developing  the  security 
kernel.  In  the  sixth  chapter  these  commands  are  related  to  a set 
of  prototype  Multics  commands  similar  to  those  being  developed  by  the 
MITRE  Corporation. 

The  seventh  and  final  chapter  serves  as  a summary  of  our  work  to 
date  and  discusses  some  problems  which  remain  to  be  solved.  In  addi- 
tion, there  is  a discussion  of  several  issues  related  to  the  larger 
project  of  which  this  effort  is  a part. 
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2.  THE  BASIC  STRUCTURE,  SQ 
2.1  Introduction 

In  this  chapter  we  present  Sq,  our  most  abstract  level  in  the 
structured  specification  process.  In  this  specification,  the  details 
of  the  target  operating  system  are  abstracted  away  to  enable  us  to 
inspect  the  most  basic  objects  and  actions  of  the  system.  By  looking 
at  these  system  fundamentals  we  were  able  to  formulate  the  necessary 
axioms  to  restrict  the  flow  of  information  and  guarantee  that  there 
can  be  no  unauthorized  disclosure  of  information.  Because  of  its 
generality,  Sq  has  become  our  definition  of  manditory  security  satis- 
fying the  military  requirement  that  it  "permits  access  to  information 
only  as  defined  by  the  rules  governing  dispersal  of  classified  infor- 
mation" [13],  Sq  further  serves  as  a guide  for  the  subsequent  struc- 
tured specification  refinements. 

Following  the  pioneering  work  of  Lampson  [ 7 ] and  others 
we  present  Sq  as  an  abstract  system  in  which  the  information  store  is 
partitioned  into  a set  of  disjoint  reposi tories  (objects)  and  the  pro- 
cessing of  and  transferring  of  information  is  accomplished  by  a set  of 
agents  (domains  or  subjects).  The  repositories  are  viewed  as  passive 
information  storing  elements.  The  information  stored  in  a repository 
can  only  be  changed  by  one  of  the  agents,  and  such  modifications  can 
only  be  detected  by  other  agents  through  an  observation.  Since  in  this 
structure  all  transfers  arp  from  repository  to  repository  through  an 
agent,  it  is  possible  to  control  information  flow  by  controlling  the 
observation  and  modification  privileges  of  each  of  the  agents. 
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Since  the  repository  is  the  smallest  unit  of  information  storage 
to  which  observation  and  modification  access  is  controlled,  all  infor- 
mation stored  in  a repository  is  considered  to  be  of  uniform 
sensitivity.  As  a measure  of  this  level  of  sensitivity,  a security 
class  is  associated  with  each  repository.  The  set  of  repositories 
is  subdivided  into  disjoint  subsets  of  repositories  with  the  same 
security  class;  each  subset  will  therefore  have  the  same  mandatory 
access  restrictions. 

Rather  than  keep  lists  specifying  which  agents  can  access  which 
set  of  repositories,  we  associate  a security  class  with  each  agent. 

The  security  class  then  becomes  the  common  measure  which  makes  the 
set  of  agents  and  set  of  repositories  comparable  and  which  can  be  used 
to  determine  what  observations  and  modifications  are  to  be  permitted. 

For  motivation  of  the  method  of  solution  and  of  the  terminology, 
let  us  consider  the  Air  Force  regulations  and  procedure  for  preventing 
compromise  of  classified  information.  For  this  purpose,  repositories 
are  documents,  and  agents  are  personnel.  The  security  class  of  a 
document  is  its  classification,  and  the  security  class  of  an  indivi- 
dual is  his  clearance.  An  individual  may  read  (observe)  a document 
only  if  its  classification  is  less  than  or  equal  to  his  clearance. 
Notice  that  this  is  a necessary  but  not  a sufficient  condition.  It 
gives  a basis  for  controlling  observations,  but  there  must  also  be  a 
basis  for  determining  which  modifications  should  be  allowed.  Recall 
that  our  objective  is  to  prevent  unauthorized  disclosure. 

Therefore,  though  not  explicitly  required  by  the  Air  Force  regu- 
lations information  must  not  be  transferred  to  a repository  with  a se- 
curity class  lower  than  that  of  the  source  repository.  To  prevent  agents 
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from  transferring  information  to  a reposity  with  insufficeint  se- 
curity class,  an  agent  will  not  be  allowed  to  modify  a repository 
unless  its  security  class  is  greater  than  or  equal  to  that  of  the  agent. 

In  order  to  discuss  this  comparison  between  elements  we  must 
define  a relation  on  the  set  of  security  classes.  Let  us  consider 
what  properties  the  relation  must  have.  Certainly  an  agent  with  a 
given  security  class  (clearance)  should  be  allowed  by  the  mandatory 
security  system  to  observe  or  modify  any  repository  with  the  same 
security  class  (classification).  Then  since  every  security  class 
must  be  less  than  or  equal  to  itself,  the  relation  must  be  reflexive. 

In  order  to  allow  possible  information  transfer  from  one  repository 
to  another  through  one  or  more  intermediate  repositories,  it  is  ne- 
cessary that  the  relation  be  transitive. 

According  to  Popek  [ 10  ] in  his  general  treatment  of  access 

maps  using  restriction  graphs,  the  relation  on  the  set  of  security  clas- 
ses can  be  a partial  ordering.  However,  antisymetry  is  not  essential 
for  the  basic  theorem  of  this  chapter  and  it  is  sufficient  to  assume 
that  the  relation  on  the  set  of  security  classes  is  a pre-ordering. 

Conceptually  a repository  is  any  information  storing  element 
in  the  system.  More  practically,  however,  a repository  can  be  looked 
upon  as  any  object  in  the  system  which  can  be  modified  in  such  a way 
that  this  modification  can  be  subsequently  observed.  The  proposed 
Sq  specification  is  intended  to  be  sufficiently  general  to  include 
all  possible  information  channels.  We  believe  that  to  leave  large 
classes  of  potential  information  channels  to  be  haphazardly  discovered 
and  dealt  with  by  the  system  implementer  is  to  circumvent  the  very 
idea  of  design  through  structured  specification. 
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2.2 


Basic  Elements,  Functions,  and  Relations 


We  now  introduce  some  notation  and  formalize  the  ideas  discussed 
in  the  preceding  section. 

The  mathematical  structure  for  mandatory  security  in  an  informa- 
tion processing  system  is  an  8-tuple: 


S0  = (R,A,C,Q,\i,<,CIi,CjU) 


where 


R 

A 

C 

9 c A x R 


y c A X R 

< c r x c 
CZ& : R + C 


C-f/t.’  A -*•  C 


is  a set  of  repositories. 

is  a set  of  agents. 

is  a set  of  security  classes. 

is  the  "observe"  relation,  (a  9 r_ means  that  agent 
a^  can  observe  the  information  stored  in  repository 

L.) 

is  the  "modify"  relation.  (a_  p r_  means  that  agent 
a^  can  modify  the  information  stored  in  repository 
r.) 

is  a pre-ordering  of  the  set  of  security  classes, 
is  the  "classification"  function  which  associates 
a security  class  with  each  repository.  (Informally 
C£i(r.)  will  be  referred  to  as  the  classification 
of  repository  r\ ) 

is  the  "clearance"  function  which  associates  a 
security  class  with  each  agent.  (Here  again 
CJtn(a)  will  be  referred  to  as  the  clearance  of 
agent  a^. ) 
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The  structure  Sq  can  be  illustrated  by  the  following  picture: 
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The  mathematical  structure  Sq  has  four  axioms.  The  first  two 
are  technical  axioms  which  simply  state  explicitly  that  the  relation 
< is  a pre-ordering  of  the  set  C of  security  classes. 

AO. 1 (Reflexivity) : For  all  c e C,  c < c. 

AO. 2 (Transitivity):  For  all  c,  d,  e e C,  c <d  and  d < e 

impl ies  c < e. 

The  second  two  axioms  state  the  rules  governing  the  acquisition  and 
dissemination  of  information  by  agents. 

AO. 3 (Acquisition):  For  all  a e A and  r e R,  a 0 r implies 

Cli>(r)  < CVi{ a).  (That  is,  if  agent  a^  can  observe  repo- 
sitory then  the  clearance  of  a^  must  be  greater  than 
or  equal  to  the  classification  of  jr. ) 

AO. 4 (Dissemination):  For  all  a e A and  r e R,  a y r implies 

COi(a)  < C£a(r).  (That  is,  if  an  agent  a^  can  modify  re- 
pository £,  then  the  clearance  of  a^  is  less  than  or  equal 
to  the  classification  of  r.  Agent  a^  can  modify  only  those 
repositories  with  equal  or  higher  security  class.) 

Using  these  four  axioms,  we  now  prove  that  in  SQ  no  information 
can  ever  be  transferred  to  a repository  in  which  it  can  be  observed 
by  an  agent  that  does  not  have  sufficient  clearance  to  observe  the 
source  repository. 

In  preparation  for  the  formal  statement  and  proof  of  the  basic 
security  theorem  about  Sq,  we  make  the  following  definitions.  Define 
the  "transfer"  relation  t £ R x R by  r t s if  and  only  if  there 
is  an  agent  such  that  a_  0 r and  a_  y s_,  where  _r  and  s^  are  reposi- 
tories. Thus  r i s means  that  there  is  an  agent  which  can  trans- 
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fer  information  from  repository  £ to  repository  £.  It  is  actually 

the  transitive,  reflexive  closure  t*  of  t which  is  needed  in  the 

theorem,  since  £ t*  £ means  that  information  can  eventually  be  trans- 
ferred from  £ to  £.  Specifically  r x*  s means  a sequence  of  agents 
and  repositories  exists  through  which  information  could  be  transferred 
from  r_  to  £.  Accordingly,  we  say  an  information  transfer  path  exists 

from  r^  to  £ when  the  relation  r x*  s holds. 

THEOREM 

T0.1:  If  there  is  an  information  transfer  path  from  repository 

£ to  repository  £ in  Sq,  then  Ch>(r)  £ Clt>{ s), 

PROOF:  By  definition,  if  there  is  an  information  path  from  repo- 

sitory £ to  repository  £,  then  £ x*  £.  We  first  establish 
that  £ x £ implies  C£6(r)  £ Clt>[s ).  For  if  £ x £,  then 
there  is  an  agent  £ such  that  £ 0 £ and  £ y £.  By  axioms 
AO. 3 and  AO. 4,  Ct6(£)  a)  and  C£/i(a)  £ C£t>{ s).  By 

transitivity  of  £,  Cl6  (£)  < Cl6 ( s). 

Now  define  a new  relation  X c_  R x R by  £ x £ if  and 
only  if  CL s(r)  £ C£a( s).  (That  is,  £ x £ means  the  se- 
curity class  of  £ is  "less  than  or  equal"  to  the  security 
class  of  £. ) Notice  that  X is  a reflexive  and  transitive 
relation.  For  any  £ e R,  axiom  A0.1  states  that  Cl6(r)  £ 
Cl6{r),  and  so  £ X £ ( i . e . , X is  reflexive)  by  the  de- 
finition of  the  relation  X.  If  £,  £,  £ e R,  such  that 
£ x £ and  £ X £,  then,  by  the  definition  of  X,  CL&(r)  £ 

CL6 {s)  and  CH ( s ) £ CL& (£) . 
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By  axiom  AO. 2,  C£a(r.)  £ Cl&{ t),  and,  again  by  definition 
of  X,  £ X jt  (i.e.,  X is  transitive). 

The  relation  X contains  the  relation  t,  since  r_  t s_ 
implies  C£6(r)  < C-U ( s ) , which  implies  jr  X s_.  Recall  that 
by  definition  of  the  transitive  closure,  the  relation  t* 
is  the  minimal  transitive,  reflexive  relation  containing 
the  relation  x.  It  follows  that  the  relation  x*  is  con- 
tained in  the  relation  X.  This  proves  the  theorem,  since, 
for  £,  £ e R,  r_  x*  ^ implies  jr  X s_,  which  implies  Ct6(r) 

< C£a( s) . 
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2.3  The  Air  Force  Security  Lattice 


In  this  section  we  hope  to  demonstrate  the  applicability  of  Sq  to 
a system  which  enforces  the  Air  Force  clearance/classification  and  com- 
partmentalization  restrictions.  We  do  this  by  showing  that  these  two 
schemes  (Clearance,  Compartments)  can  be  combined  to  give  a single 
set  of  security  classes.  Air  Force  "need-to-know"  restrictions  have 
not  been  included  because,  as  will  be  discussed  later,  strict  mandatory 
enforcement  of  need-to-know  gives  a system  of  limited  usefulness,  and 
it  does  not  model  the  actual  military  use  of  need-to-know. 

Let  us  now  write  out  the  details  of  the  security  lattice  which 
describes  the  Air  Force  classification  system.  Let  Sen  be  the  set  of 
sensitivity  levels  (i.e.,  unclassified,  confidential,  secret,  etc.). 

Sen  is  a iattice  because  it  is  linearly  ordered. 

Let  Cmp  be  the  set  of  compartments  of  subject  matter  (China,  nu- 
clear, etc.).  Generally  the  information  stored  in  a given  repository 
may  be  included  in  more  than  one  compartment;  hence,  the  component  of  a 
security  class  concerned  with  compartmentalization  will  actually  be  a 
subset  of  compartments  to  which  the  information  belongs.  Although  all 
possible  subsets  of  Cmp  may  not  be  needed  in  practice,  our  formal 
treatment  will  use  the  entire  power  set  P(Cmp)  of  Cmp.  P(Cmp)  is  a 
lattice  naturally  ordered  by  set  inclusion.  The  two  lattices  Sen  and 
P(Cmp)  can  be  combined  to  form  the  product  Sen  x P(Cmp)  which  is  itself 
a lattice  [8,  p.  489  ] with  order  relation  defined  as  follows: 
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for  (c,D),(e,F)eSen  x P(Cmp),  (c,D)  ± (e,F)  if  and  only  if  £<.  e in  Sen 
and  D £ F in  P(Cmp).  Thus  an  agent  may  observe  a repository  only  if 
the  classification  level  of  the  repository  is  less  than  or  equal  to  the 
clearance  level  of  the  agent  and  the  set  of  compartments  associated 
with  the  repository  is  a subset  of  the  set  of  compartments  associated 
with  the  agent. 

Since  the  set  CQ  = Sen  x P(Cmp)  is  a lattice,  under  the  ordering  £ 
defined  above,  axioms  A0.1  and  AO. 2 will  be  satisfied.  Being  a lattice, 
CQ  has  stronger  properties  than  required  for  mandatory  security  as  de- 
fined by  SQ.  While  not  necessary,  those  additional  properties  may  be 
useful  in  practice.  For  example,  given  any  two  classes  in  CQ,  there 
is  a minimal  class  which  is  greater  than  or  equal  to  either  one.  Also, 
CQ  has  a greatest  and  a least  element. 

The  basic  theorem  T0.1  then  states  that,  in  a system  which  uses 
the  Air  Force  security  lattice  CQ  to  restrict  the  observe  and  modify 
relations  according  to  axioms  AO. 3 and  AO. 4,  there  can  be  no  transfer  of 
information  from  a repository  with  one  sensitivity  and  set  of  compart- 
ments to  a repository  with  lower  sensitivity  or  smaller  set  of  compart- 
ments. Also,  since  the  only  access  to  repositories  is  through  agents, 
there  can  be  no  unauthorized  disclosure  of  information. 

The  modeled  system  is  quite  similar  to  the  real  world  except  for 
axiom  AO. 4 which  states  that  an  agent  may  not  modify  a repository  with 
lower  security  class.  Under  that  restriction,  if  agents  are  acting  on 
behalf  of  system  users,  a user  who  has,  say,  secret  clearance  could  not 
send  any  information  to  an  uncleared  user  through  the  system.  This  is 
necessary  since  the  system  cannot  interpret  which  information  is  clas- 
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sified  and  which  is  not. 

To  realistically  apply  the  basic  theorem  to  the  Air  Force  security 
procedure,  we  might  suggest  that  a person  be  allowed  to  operate  as  an 
agent  with  any  clearance  up  to  and  including  his  actual  clearance.  This 
places  the  responsibility  on  the  user  to  decide  at  which  level  he  should 
operate.  In  making  the  decision  to  operate  at  a reduced  clearance,  the 
user  relinquishes  the  right  to  observe  any  material  classified  higher 
than  his  "working  level."  In  this  way  axiom  AO. 4 can  be  satisfied  and 
the  result  of  the  theorem  ensured. 
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2.4  Need  To  Know  Security  Enforcement 


The  Air  Force  further  ensures  the  privacy  and  integrity  of  infor- 
mation by  requiring  that  to  access  information  one  must  not  only 
have  proper  clearance  but  must  also  have  established  a "need-to-know" 
for  the  information.  The  fact  that  Jones  is  cleared  to  see  material 
in  a given  security  class  does  not  mean  he  can  read  a document  with 
that  classification  written  by  Smith,  unless  he  has  been  extended  the 
proper  need-to-know  authorization. 

Initially  we  attempted  to  include  the  need-to-know  security  scheme 
in  the  basic  security  model  by  incorporating  it  into  a lattice  struc- 
ture. However,  this  security  structure  proved  much  too  rigid  to  be  of 
any  use,  except  perhaps  in  the  special  case  of  a small  environment. 

As  an  alternative  to  this  lattice  type  structure  we  present  a less 
strict  need-to-know  security  system  in  which  the  responsibility  for 

protecting  the  contents  of  repositories  is  left  to  the  individual  users. 
We  will  refer  to  this  system  as  the  Discretionary  Security  System. 

This  system  involves  attaching  to  each  repository  a list  of  users 
who  are  allowed  to  observe  the  contents  of  that  repository.  There  is 
a major  disadvantage  to  this  system:  if  we  let  user  Smith  observe  one 

of  our  repositories,  we  cannot  be  certain  that  he  will  not  pass  the 
contents  along  to  user  Jones.  This  is  similar  however  to  the  real 
world  situation. 

An  advantage  of  the  discretionary  security  system  is  that  we  only 
have  to  check  whether  one  user  is  on  a need-to-know  list  rather  than 
having  to  check  whether  one  list  of  users  is  contained  in  another  list 
of  users.  Checking  for  individual  membership  is  usually  much  faster 
than  checking  for  containment. 
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There  is  another  security  problem  which  the  discretionary  security 
system  should  confront,  and  that  is  the  problem  of  sabotage.  We  could 
construct  a strict  "need-to-modify"  security  system  to  deal  with  this 
problem,  but  it  would  be  just  as  cumbersome  as  the  strict  "need-to- 
know"  system.  The  proposed  discretionary  security  system  will  deal  with 
this  problem  by  attaching  to  each  repository  a list  of  users  who  are 
allowed  to  modify  the  contents  of  that  repository. 

Since  the  discretionary  security  is  not  as  strict  about  control- 
ling access  to  repositories  as  the  mandatory  security  is,  we  will  pro- 
vide the  user  with  additional  mechanisms  for  controlling  his  agents. 
These  will  take  the  form  of  agent  privileges  which  the  user  may  se- 
lectively revoke. 
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2.5  The  Relationship  Between  Successive  Levels  of  Structured 
Specification 

Sq  has  both  intuitive  appeal  and  formal  simplicity.  The  major 
design  requirement  that  the  system  permit  no  compromise  of  information 
has  been  achieved  and  controlled  sharing  of  multi-level  information 
has  been  accounted  for.  All  that  is  needed  is  to  look  at  an  actual 
computing  system,  show  that  the  specifications  which  completely  de- 
fine Its  operation  can  be  formulated  into  a precise  mathematical 
structure,  demonstrate  that  these  formal  specifications  are  consistent, 
and  that  the  four  axioms  of  SQ  hold  under  the  interpretation. 

This  procedure  is  trivial  for  a trivial  system,  however  it  is  not 
at  all  clear  how  it  can  be  applied  directly  to  a complex  operating 
system  such  as  Multics.  The  formalism  of  axiomatic  systems  has  been 
used  to  concisely  formulate  the  intuitively  obvious  in  precise  terms, 
but  the  power  and  effectiveness  of  the  method  have  not  been  demon- 
strated. The  concept  of  Sq  is  thought  to  be  sufficiently  general  to 
describe  a broad  class  of  information  security  problems  including  ap- 
plications which  use  the  Air  Force  sensitivity-catagory  classification 
lattice  as  their  set  of  security  classes  and  to  permit  software  imple- 
mentation in  a segmented  architecture.  However  it  gives  little  direc- 
tion towards  actual  implementation. 

The  technique  of  structured  specification  will  now  be  illustrated 
by  giving  a second  level  structure  which  will  satisfy  the  security  re- 
quirements in  Sq  plus  further  design  requirements  to  describe  a file 
system  structured  as  a tree  of  arbitrary  depth  and  a mechanism  for 
"inter-agent"  communication  which  does  not  require  accessing  a shared 
file.  These  additional  restrictions  make  the  design  more  implementa- 
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tion  specific.  We  note  further  that  such  additional  structures  are 
not  required  for  prevention  of  compromise  of  security  but 
are  to  analyze  certain  design  decisions  at  an  abstract  level  of  dis- 
cussion before  formal  specifications  for  implementation  are  attempted. 

At  each  new  level  of  specification,  additional  restrictions  will 
be  imposed.  Difficulties  in  formulating  a consistent  axiomatic  system 
which  validly  interprets  the  preceding  structure  and  satifies  the  new 
restrictions  can  indicate  two  different  problems.  Either  the  newly 
added  restrictions  are  not  compatable  with  a secure  design  or  the  pre- 
vious level  was  not  appropriate.  The  first  case  demands  a change  in 
design  decision  at  the  new  level;  the  second  calls  for  a reformulation 
of  the  preceding  level.  The  technique  is  thus  one  of  successive,  pos- 
sibly reiterated,  refinements  of  design  requirements  each  followed  by 
a consistent  formal  specification  which  validly  interprets  the  pre- 
vious structure  and  which  incorporates  the  new  design  concepts.  The  pro- 
cess is  complete  when  at  some  level  the  mapping  between  formal  symbols 
and  actual  system  objects  is  a trivial  identification  and  all  desired 
restrictions  have  been  incorporated.  At  this  point,  formal  proof  of 
the  security  of  the  final  structure  is  a relatively  straightforward  result 
of  composing  the  several  one-to-one  correspondences  between  levels  to 
yield  a single  correspondence  between  it  and  the  Sq  specification. 

Proving  the  entire  system  will  also  require  establishing  that  all  the 
axioms  of  the  final  level  do  ir.  fact  hold  in  the  implementation  of 
the  system. 

As  noted  before,  because  of  its  generality  and  intuitive  obvious- 
ness it  is  not  expected  that  it  will  be  necessary  to  reformulate  Sq. 
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Beyond  that  it  is  hoped  that  reiteration  can  be  minimized  by  informally 
weighing  the  expected  consequences  of  design  decisions  before  their 

formalization.  The  possibility  of  the  need  to  backup  and  modify  a pre- 
vious level  should  not  be  construed  to  be  a weakness  of  the  method  in 
the  sense  that  the  formal  system  at  any  level  is  at  sometime  not  se- 
cure. The  machinery  of  the  axiomatic  method  precludes  this.  The 
need  to  reiterate  indicates  a weakness  in  the  designer  in  that  he  is 
unable  to  comprehend  a complex  operating  system  and  to  make  all  the 
correct  decisions  in  one  step.  Structured  specification  then  is  a tool 
which  allows  the  designer  to  proceed  a step  at  a time  toward  his  ul- 
timate goal.  Each  step  is  guided  by  previous  steps,  by  previous  mis- 
taken steps,  and  by  general  intuitive  notions  about  the  final  goal. 
Since  the  designer  does  not  know  precisely  where  he  wants  to  go  he 
must  accept  the  probability  of  making  a few  wrong  steps  along  the  way. 
Incorrect  steps  may  provide  further  insight  about  the  system  design. 
Also,  since  no  code  will  have  been  written  nor  logic  built,  the  cost 
of  a mistaken  step  will  be  minimal. 
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3.  THE  S]  STRUCTURE:  FILE  AND  MAILBOX  STRUCTURES 

3.1  Introduction 


The  Sq  structure  defined  information  security  with  an  abstract, 
presumably  intuitive,  description  of  a secure  system.  This  chapter 
presents  a structure,  S-| , relating  the  Sq  definition  of  security  to 
computer  system  design.  The  development  of  two  basic  features  of 
modern  computer  systems,  file  systems  and  processes,  will  be  initiated. 
The  repository  concept  of  Sq  is  refined  by  subdividing  the  set  of 
repositories  into  two  distinct  subsets.  One  subset  is  explicitly 
structured  as  a tree  of  files.  The  other  subset  of  repositories  pro- 
vides a mechanism  for  communication  between  agents. 
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3.2  File  and  Mailbox  Structures 


A subset  of  Sq  repositories  is  identified  in  as  files  (called 
segments  in  Multics).  To  reflect  the  Multics  directory  naming  scheme 
of  addressing  segments  we  organize  these  files  into  a tree  structure. 

To  store  or  retrieve  information  in  a given  file,  the  file  system  must 
be  searched  from  the  root  until  the  file  has  been  found;  therefore, 
restrictions  must  be  imposed  on  the  relationships  between  files'  lo- 
cations in  the  tree  and  their  classifications.  These  restrictions  are 
developed  in  the  axiomatic  description  of  section  3.3. 

Agents  can  communicate  through  the  modification  and  subsequent 
observation  of  files.  This  method  of  communication  however  would  be 
subject  to  all  the  restrictions  imposed  on  the  file  structure.  It  is 
desirable  to  provide  a less  cluttered  mechanism  devoted  to  communica- 
tion between  agents;  therefore,  we  introduce  a non-file  communication 
path  between  agents.  The  mechanism  modeled  will  be  sufficient  to  im- 
plement those  features  which  Multics  provides. 

Objects  such  as  Multics'  event  charnels  and  semaphores  could  be 
named  globally  and  referenced  through  the  file  system.  Instead  we  de- 
signate as  mailboxes  a subset  of  the  set  of  Sq  repositories.  Mailboxes 
are  not  files  and  are  not  restricted  by  file  considerations  and  usages. 

Being  repositories,  mailboxes  do  have  classifications,  and  agents  can 
in  the  Sq  sense  observe  and  modify  them.  Two  new  relations,  send  and 
receive,  provide  agents  the  ability  to  communicate  through  mailboxes. 
Sending  to  and  receiving  from  mailboxes  vi 1 1 be  restricted  with  the 
necessary  assertions  governing  the  use  of  them.  The  mechanism  thus 
designed  should  be  general  enough  to  supoort  more  refined  mechanisms. 
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Since  an  agent's  passing  information  to  another  agent  of  higher 
classification  does  not  compromise  security,  agents  may  send  to  mail- 
boxes of  equal  or  higher  classification  but  not  to  lower  classifica- 
tions. Receiving  from  a mailbox  may  constitute  both  an  observe  and  a 
modify  in  the  Sq  sense  depending  upon  the  implementation  of  the  mailbox 
mechanism.  A mailbox  mechanism  is  likely  to  be  implemented  as  a mes- 
sage queue;  an  agent's  receiving  a message  would  involve  observing 
the  message  and  removing  it  from  the  front  of  the  queue.  This  removal 
can  be  observed  by  another  agent  if  the  mailbox  has  classification  equal 
to  or  lower  than  the  agents  clearance.  (See[14,  appendix  B]  for  further 
explanation.)  By  the  Sq  observe  restrictions,  receiving  must  be  from  a 
mailbox  of  equal  or  lower  classification  than  the  agent  receiving;  how- 
ever, the  modify  restriction  disallows  receiving  from  a lower  classifi- 
cation. Agents  therefore  may  receive  only  from  mailboxes  having  clas- 
sification equal  to  their  clearance.  Communication  between  agents  of 
unequal  clearances  can  occur  since  sending  to  higher  classifications  is 
allowed.  As  necessitated  by  Sq  an  agent  may  not  communicate  information 
down  to  an  agent  of  lower  classification. 

The  restrictions  on  the  send  and  receive  relations  are  applicable 
whether  the  implemented  operations  are  strictly  simple  synchronizing 
signals  or  whether  the  operations  permit  the  transmission  of  a message 
with  the  signal.  These  restrictions  are  stated  explicitly  in  the  axioms 
which  follow. 

In  more  refined  structures  communication  between  agents,  interagent 
communication,  will  be  refined.  When  processes  are  introduced,  mail- 
boxes will  provide  the  means  for  interprocess  communication. 
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3.3  The  Mathematical  and  Axiomatic  Structure  of 

The  structure  for  mandatory  security  in  an  information  processing 
system  with  hierarchically  structured  files  and  inter-agent  communica- 
tion is  the  following: 


S1 

(F, M,  A,  C,  Pp,  Op  »P^j>  C-Ca  , C£/l) 

where 

F 

is  a tree  of  files  (directories  and  segments) 

M 

is  a set  of  mailboxes 

A 

is  a set  of  agents 

C 

is  a set  of  security  classes 

pp  c A x F 

is  the  "retrieve  information"  relation. 

(a  Pp  f means  that  agent  a can  retrieve  information 
from  file  f . ) 

Pp  c A x F 

is  the  "store  information"  relation,  (a  Op  f means 
that  agent  a can  store  information  in  file  f.) 

£ A x M 

is  the  "receive"  relation,  (a  p^  m means  that  agent 
a can  receive  information  through  mailbox  m.) 

c A x M 

is  the  "send"  relation,  (a  o^  m means  that  agent  a 
can  send  information  to  mailbox  m.) 

c C x C 

is  a pre-ordering  of  the  set  of  security  classes. 

6 c F x F 

is  the  "dominate"  relation  on  the  set  of  files. 
(It  defines  the  "tree"  structure  on  the  files.) 

Cli>:F  u M + C 

is  the  "classification"  function  for  files  and  mailboxes 

ce*:  A + C 

is  the  "clearance"  function  for  agents. 
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M-j  can  be  illustrated  by  the  following  diagram: 


A 


We  now  list  the  axioms  for  . 

A1 .1 : For  all  c e c>  c <_  c (<_  is  reflexive) . 

A1.2:  For  all  c,  d,  e e C,  c ^ d and  d ^ e implies  c ^ e 

is  transitive). 

The  next  four  axioms  impose  restrictions  on  the  store,  retrieve,  send, 
and  receive  relations  in  order  that  S-j  ray  validly  interpret  Sq.  The 
retrieve  and  receive  relations  correspond  to  observation  and  the  store 
and  send  relations  to  modification. 

A1.3:  For  all  a e A and  f e F,  a Pp  f implies  CIa( f)  CV i(a) 

(An  agent  can  only  "retrieve"  information  from  a file 
with  equal  or  lower  classification.) 

A1.4:  For  all  a e A and  m e M,  a m implies  C&$(m)  = Cln( a) 
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(An  agent  can  only  "receive"  information  through  a 
mailbox  with  classification  equal  to  its  own  clearance.) 


A1.5: 

For  all  a e A and  f e F,  a ap  f Implies  Cln( a)  CLf>{ f) 
(An  agent  can  only  "Store"  information  In  a file  with 
equal  or  greater  classification.) 

A1.6: 

For  all  a e A and  m e M,  a m Implies  Cln{ a)  < CZt>{ m) 
(An  agent  can  only  "send"  information  through  a mailbox 
with  equal  or  greater  classification.) 

The  tree  structure  on  the  set  of  files  is  asserted  by  the  following: 

A1.7: 

For  all  f e F,  f 6 f (6  is  reflexive). 

A1.8: 

For  all  f,  g e F,  f i g and  g 6 f implies  f = g. 
(6  is  antisymmetric). 

A1.9: 

For  all  f,  g,  h e F,  f 6 g and  g s h implies  f 6 h. 
(6  is  transitive). 

A1.10: 

For  all  f,  g,  h e F,  g 6 f and  h 6 f implies  g 6 h or 
h 6 g $ has  the  "tree"  property). 

The  remaining  axioms  formailize  the  use  of  tree  structure  on  the  files 
as  a directory. 

Al.ll: 

For  all  a e A,  and  f,  g e F,  a pp  g and  f 6 g implies 

a pp  f.  (In  order  to  retrieve  information  from  a file, 
an  agent  must  be  able  to  retrieve  from  (i.e.  search)  every 
file  which  dominates  it.  This  axiom  recognizes  certain 
implicit  information  paths  which  result  from  the  nature 
of  the  directory  system.  To  illustrate  the  difficulty, 
suppose  that  an  agent  a^  deletes  a directory  £ which 
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dominates  a file  £;  then  another  agent  £ can  tell  that 
the  file  £ is  no  longer  observable.  This  constitutes 
a potential  communication  path  between  a_'  and  £.  In 
effect,  £ can  make  a limited  observation  of  directory 
£ by  determining  whether  file  £ is  still  observable. 

(See  Lampson  [6]  for  a discussion  of  similar  problems.)) 

A1.12:  For  all  a e A,  and  f,  g e F,  if  a crp  g and  f 6 g and  f / g 

then  a Pp  f.  (In  order  to  store  into  a file,  an  agent 

must  be  able  to  retrieve  from  or  search  every  file  which 
strictly  dominates  it.  Note  that  it  is  possible  for  an 
agent  to  store  into  a file  which  he  is  not  allowed  to 
read;  thus.,"writing-up"  to  a higher  classification  is 
allowed.  Any  implementation  which  permits  such  "writing- 
up"  must  be  careful  to  avoid  introducing  any  implicit 
information  paths.  For  example,  if  an  error  occurs  in 
writing  to  a file  of  higher  classification,  no  error 
message  may  be  given;  otherwise,  this  would  provide  a 
method  of  communication  from  higher  to  lower  classifi- 
cation. ) 

Proposition  3.0:  For  any  agent  in  A and  any  files  f and  g in  F, 

if  a ap  g and  fag,  then  Ct&( f)  £ Cf4(g). 

(A  file  which  can  be  modified  by  some  agent  must  have 
a classification  which  is  greater  than  or  equal  to  the 
classification  of  any  directory  which  eventually  con- 
tains it.) 
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The  proof  of  Proposition  3.0  follows  from  previous  axioms: 

Axiom  A1.5  says  that,  if  a ap  g,  then  C£a( a)  * Cl&( g).  Now  note  that 
A1.12  asserts  that,  if  a then  a ppf.  By  axiom  A1.3  CJU{ f) 

<3  Cln{ a).  Using  the  transitivity  of  ^ (Ax2),  C£a(f)  < CVi{ a)  « Cl6{ g) 
Implies  CLt>{ f)  £C£4(gl  as  desired. 

The  implications  of  Proposition  3 are  clearer  if  we  state  it  in 
contrapositive  form. 

Corollary  1 : For  any  agent  a in  A and  files  f and  g in  F,  if  f 5 g 

and  Ch>[f)  Cl6( g),  then  not  a op  g. 

(No  agent  can  modify  a file  £ which  is 
contained  in  a directory  whose  classifi- 
cation is  not  less  than  or  equal  to  the 
classification  of  the  file  £. ) 

This  corollary  motivates  us  to  introduce  another  axiom  in  order  not  to 
have  a file  system  which  is  cluttered  with  useless,  unmodifiable  files. 

A1.13  For  any  files  f and  g in  F,  if  f $ g,  then  Ch>( fl  <_ 

Cfc6(g).  (Every  directory  has  an  equal  or  lower  classifi- 
cation than  any  file  it  eventually  contains.  The  root 
of  a directory  tree  must  nave  the  lowest  classification 
existing  in  the  tree;  furthermore,  the  sons  of  any  node 
in  the  tree  can  be  classified  no  lower  than  that  node.) 
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3.4  The  Consistency  of  S-j  and  its  Relationship  to  Sq 


An  S-|  structure  has  been  described  and  the  formal  axioms  of  the 
structure  have  been  stated.  It  is  necessary  to  formalize  the  relation- 
ship between  the  S-j  structure  and  the  Sq  structure;  S-|  must  be  proved 
to  be  a refinement  of  Sq.  The  formal  statements  and  detailed  proofs  of 
this  assertion  are  in  appendix  B of  this  report. 

All  objects  in  the  S-j  structure  must  be  shown  to  be  instances  of 
objects  in  the  more  abstract  Sq  structure.  A proposition  is  stated 
and  proved  that  a one-to-one  mapping  from  S-|  to  Sq  exists  so  that  the 
relations  of  Sq  are  preserved.  To  complete  the  proof  of  refinement, 
it  is  formally  shown  that  every  valid  interpretation  of  S-|  (S-|  type 
structure)  is  a valid  interpretation  of  Sq  and  consequently  any  theorem 
of  Sq  is  true  in  S-j  also. 

Although  it  is  not  necessary  in  proving  that  S^  is  indeed  a refine- 
ment of  Sq,  a proposition  states  that  S-j  is  consistent,  that  is,  that 
no  self  contradictions  exist  within  it.  The  proposition  is  proved  by 
constructing  a specific  S-|  type  structure  which  satisfies  the  axioms. 

If  S-j  was  not  consistent  no  such  example  could  be  constructed.  Although 
S-j  need  not  be  consistent  to  be  an  interpretation  of  Sq,  this  proposi- 
tion is  proved  first  since  an  inconsistent  structure  would  be  of  no  value 
in  the  structured  specification  process. 
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4. 


FORMALIZATION  OF  DYNAMIC  SECURITY 


4.1  Introduction 


As  we  progress  from  the  very  abstract  description  of  controlled 
information  sharing  to  a more  complex  structure  which  can  serve  as  a 
formal  specification  for  the  Implemented  system,  we  must  make  certain 
design  decisions.  For  example,  the  file  concept  introduced  in  S-|  was 
an  abstraction  of  an  information  bearing  object.  Beyond  the  facts  that 
each  file  had  an  associated  classification  and  that  files  were  organized 
hierarchically  nothing  was  assumed  about  other  attributes  of  the  files. 

A further  simplification  in  is  the  lack  of  any  consideration  of 
time-variant  aspects  of  an  actual  system.  At  this  point  it  is  time  to 
look  at  available  technology  and  make  some  decisions  about  feasible 
ways  of  implementing  the  relationships  asserted  in  S-| . 

It  was  demonstrated  in  chapter  2 that  the  intended  application 
of  Sq  theory  to  the  Air  Force  classification/compartmental ization 
scheme  was  possible.  If  the  resultant  lattice  of  security  classes  is 
stored  directly  as  a bit  vector  (value)  rather  than  in  some  encoded 
form  (name)  it  will  take  at  least  19  bits,  e.g.  16  compartments  and  7 
clearance  levels  for  each  security  class.  In  such  a case  parallel 
hardware  could  be  used  to  check  the  permissibility  of  each  attempted 
access  without  significant  time  overhead.  However,  if  the  files  (re- 
positories) had  only  say  36  bits  of  information  this  would  cause  an 
intolerable  storage  overhead.  Because  of  fixed  storage  requirements 
for  each  security  class  value,  storage  overhead  will  be  minimized  by 
making  the  repository  as  large  as  possible. 
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On  the  other  hand  to  obtain  the  total  mediation  required  in  a 
secure  system  there  must  be  some  mechanism  which  efficiently  does  the 
equivalent  of  checking  current  access  privilege  at  every  attempted  ac- 
cess of  a repository  (file). 

In  a conventional  system  in  which  all  accesses  to  the  file  system 
are  under  the  control  of  a file  system  manager  it  would  be  reasonable  to 
assign  classification/compartment  values  to  each  file  and  to  interpret 
the  controller  observe  and  modify  type  accesses  of  S-|  to  be  reading 
and  writing  into  the  file  system  under  the  auspices  of  the  file  system 
manager.  The  security  of  information  contained  in  the  files  could  in 
theory  be  ensured  by  including  security  checking  mechanisms  in  the  file 
manager  itself;  e.g.,  a file  could  only  be  opened  for  reading  by  a pro- 
cess with  clearance  equal  to  or  greater  than  the  classification  of  the  file. 
A major  problem  with  this  approach  is  that  the  security  of  information 
in  files  depends  directly  upon  the  continued  integrity  of  the  file 
system  manager, the  operation  of  which  would  have  to  be  verified  to  be 
correct  and  to  be  guaranteed  unmodifiable  by  malicious  or  errant  pro- 
grams. A second  problem  is  the  fact  that  after  information  was  read 
into  core  the  secure  file  system  manager  would  have  no  control  over 
sharing  of  information  by  processes  in  core. 

The  Multics  approach  appears  to  offer  a feasible  alternate  solu- 
tion in  which  mediation  is  rigorously  imposed  on  all  attempted  acces- 
ses by  the  dynamic  address  computation  mechanism  built  into  the  hard- 
ware. Linder  the  Multics  virtual  memory  all  processor  accesses  to  me- 
mory can  be  considered  to  be  accesses  to  the  file  system  and  vice  versa. 
There  is  no  logical  distinction  between  accessing  a word  in  core*  on 
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disk,  or  in  the  paging  device.  All  accesses  to  storage  in  Multics 
are  indirected  through  a segment  descriptor  word  (SOW)  in  a segment 
descriptor  table  which  is  maintained  for  each  process.  Among  other 
things  the  SDW  contains  the  access  privileges  of  the  process  for  the 
segment  to  which  it  points.  Correct  operation  depends  upon  maintain- 
ing the  validity  of  the  segment  descriptor  table  for  each  process  and 
upon  the  proper  functioning  of  the  supporting  segmentation  and  paging 
control  mechanisms.  At  this  level  we  will  concentrate  on  formalizing 
the  behavior  of  the  segment  table,  leaving  the  underlying  mechanism 
as  problems  of  implementation  to  be  addressed  in  later  more  detailed 
specifications. 

In  the  current  Multics  the  segment  descriptors  are  maintained  on 
the  basis  of  the  access  control  lists  (i.e.  lists  of  permitted  users) 
which  are  kept  for  each  segment.  We  propose  a similiar  procedure  where- 
by decisions  to  update  the  segment  descriptor  table  are  based  upon 
mandatory  security  restrictions.  The  present  use  of  access  control 
lists  could  be  retained  to  provide  discretionary  "need-to-know" 
security. 

In  the  following  the  term  executor  will  be  used  to  refer  to  the 
abstraction  for  process.  Since  we  are  considering  only  the  problems 
of  maintaining  information  security,  the  only  aspects  of  the  segment 
descriptors  which  we  will  discuss  are  the  "read"  and  "write"  bits 
which  control  the  observe  and  modify  type  operations.  These  bits 
will  be  abstracted  to  two  relations  the  view  and  alter  relation  which 
can  be  roughly  interpreted  to  indicate  whether  or  not  a given  file 
(segment)  has  been  connected  (i.e,  a segment  descriptor  word  has  been 
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prepared  for  it  and  entered  into  the  segment  table  of  the  appropriate 
executor).  In  order  for  information  to  move  from  a file  to  an  execu- 
tor the  view  relation  must  hold.  This  fact  will  be  asserted  as  an 
axiom  below.  Upon  the  first  attempt  to  view  a given  file  a missing  seg- 
ment-condition" will  be  raised  which  will  cause  explicit  checking  of 
mandatory  security  restrictions.  If  the  attempted  view  is  permissible 
then  the  view  relation  is  set  and  thus  any  subsequent  views  are  allowed 
without  explicit  checking.  In  this  way  total  mediation  can  be  effected 
with  no  additional  overhead  in  time  or  storage  except  at  initial  at- 
tempted access.  A similar  argument  applies  to  the  "write"  or  alter 
type  operation.  While  it  is  not  clear  how  interprocess  communication 
will  be  implemented,  we  have  proposed  similar  constructs  for  accessing 
of  mailboxes. 

The  dynamic  or  time-variant  nature  of  an  information  processing 
system  will  be  treated  by  considering  the  system  to  be  a sequence  of 
states.  During  each  state  the  system  will  remain  static  as  far  as  the 
security  relevant  conditions  are  concerned.  Thus  during  a state 
there  will  be  no  new  files  or  executors  created,  nor  any  connection 
etc.  changed.  Ordinary  computation  and  movement  of  data  will 
proceed  as  usual  during  the  state.  A transition  to  a next  state  will 
occur  whenever  some  security  relevant  change  in  the  system  is  required. 

By  the  nature  of  the  transitions  it  cannot  be  expected  that  S-|  type 
axioms  will  hold  from  one  state  to  the  next.  What  we  can  hope  to  show 
is  that  if  we  start  in  a state  which  is  S^-secure  and  if  we  restrict 
the  transition  to  a subset  of  security  preserving  transitions  then 
every  state  which  can  be  reached  through  a sequence  of  secure  transi- 
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tions  will  leave  the  system  in  a secure  condition,  that  is,  no  unauthor- 
ized disclosures  will  ever  be  allowed. 

Intuitively,  the  method  of  attack  is  to  consider  the  several  states 
with  their  component  objects  and  relations  to  be  combined  with  appropriate 
inter-state  relationships  into  a single  structure.  Then  it  must  be 
shown  that  with  reasonable  interpretation  this  new  construct  is  secure 
and  that  the  security  thus  displayed  applies  not  only  to  data  transfer 
paths  within  individual  states  but  also  to  extended  dynamic  transfer 
paths  between  states. 
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4.2  A Formal  Description  of  a Dynamic  Secure  System 


In  this  section  we  shall  propose  an  axiomatic  system  which  allows 
us  to  describe  the  time-variant  behavior  of  a secure  information  pro- 
cessing system.  At  any  given  time  we  assume  the  new  system  has  a 
structure  similar  to  S-|  in  that  it  has  sets  of  files,  mailboxes  and 
executors  (agents)  with  corresponding  relationships  and  functions,  but 
with  the  additional  flexibility  that  the  said  relations  and  functions 
may  vary  with  time.  We  shall  assume  only  that  the  set  of  security 
classes  and  its  pre-ordering  is  constant.  Thus  we  will  allow  additions 
or  deletions  to  any  of  the  sets  of  files,  mailboxes  and  executors. 

Also  the  view,  alter,  block  and  wakeup  relationships  may  be  enlarged  (i.e. 
new  connections  made)  or  diminished  (disconnections).  The  classifica- 
tion and  clearance  functions  will  also  be  allowed  to  change. 

In  order  to  describe  the  current  "state"  of  the  system  at  any  gi- 
ven time  we  shall  compose  all  security  relevant,  time  variant  informa- 
tion about  the  system  into  a substructure  called  the  state  of  the 
system. 

For  convenience  we  introduce  the  auxiliary  set,  states,  and  re- 
cord the  state  information  through  use  of  additional  relation  and  func- 
tions. Rather  than  to  give  an  extensive  list  of  axioms  for  S2  we  pre- 
fer to  describe  it  as  a nondetermini  Stic  automaton,  that  is,  in  terms 
of  possible  state  values,  and  transitions  from  state  to  state.  We  will 
define  a class  of  permissible  transitions  with  the  property  that  if  the 
S2-  system  starts  in  an  initial  state  which  is  "secure"  and  makes  only 
permissible  transitions  then  it  will  always  stay  in  a "secure"  state 
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and  furthermore  any  "dynamic"  information  transfer  paths  will  be  secure 
in  the  sense  of  S-j.  This  latter  property  will  be  established  by  show- 
ing that  the  structure  formed  by  all  states  which  are  reachable  by 
permissible  transitions  from  some  initial  secure  state  is  in  fact  an 
example  of  S^. 

Finally,  an  example  set  of  primitive  permissible  transitions  (se- 
curity events)  will  be  given  from  which,  we  claim,  any  permissible 
transitions  can  be  composed.  It  will  be  possible  to  derive  formal 
specifications  for  the  primitive  transitions,  and  it  is  these  specifi- 
cation along  with  a definition  of  an  initial  secure  state  which  will 
be  used  in  subsequent  formalization. 

At  this  level  of  abstraction  we  are  not  addressing  the  conco- 
mitant problems  involved  when  the  transitions  are  assumed  to  occur  at 
the  request  of  executors  within  the  system.  To  the  extent  that  state 
information  is  stored  in  classified  files  (or  mailboxes)  the  state 
changes  are  modifications  and  must  be  governed  by  the  usual  restrictions 
on  acquisition  and  dissemination  of  information.  The  solutions  to 
those  problems  depend  upon  additional  design  decisions  which  are  not 
necessary  to  answer  the  more  general  question  raised  in  this  chapter, 
namely,  just  what  state  conditions  are  necessary  before  a given  transi- 
tion is  to  be  permitted. 

The  formal  description  of  a dynamic  secure  system  consists  of  the 
following  structure: 
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S2 

= <E,F,M,C,S,  x,<_,  6,  3,a),c£/L,  c£a,  F,T,Ut  6 , v, 

a,  3,  to,  c3a,  > 

E 

is  a set  of  executors. 

F 

is  a set  of  files. 

M 

is  a set  of  mailboxes. 

C 

is  a set  of  security  classes. 

s 

is  a set  of  states. 

T C S x s 

the  transition  relation;  thus,  if  s x t 
we  will  say  there  is  a transition  from  s to 
t where  s and  t are  states. 

<a  C C x c 

pre-ordering  of  C. 

6C  F X F 

the  dominate  relation  on  files. 

vCEXF 

the  view  relation,  (e  v f means  executor  e 
is  connected  to  file  f for  viewing  or  reading 
information  in  the  file. 

We  assume  that  under  no  other  circumstances 
can  an  executor  acquire  information  from  a 
file. ) 

ciCT  E X F 

the  alter  relation,  (e  a f means  executor 
e is  connected  to  file  f for  writing  , that  is, 
the  write  bit  is  set.) 

g C E X M 

the  block  relation,  (e  6 m means  that  executor 
e can  interrogate  mailbox  m and  if  no  message 
is  available  wait  until  one  is  received.  In 
current  implementation  there  is  no  counterpart 
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to  the  segment  descriptor  word  for  mail- 
boxes (or  event  channels);  it  is  con- 
sidered sufficient  to  have  the  "name"  of  a 
mailbox  in  order  to  use  it.  For  security 
it  will  be  necessary  to  check  classification/ 
clearance  restrictions  before  disclosing  the 
"name"  or  else  explicit  checks  will  be  ne- 
cessitated at  each  requested  access.) 

B c ExM  the  wakeup  relation,  (e  u m means  executor 
e can  send  a message  to  another  executor 
which  is  blocked  on  mailbox  m or  will  block 
on  m at  some  later  time.) 

cJUi  £ E x C the  clearance  relation.  (Since  any  executor 
may  have  different  clearances  in  different 
states  clearance  is  no  longer  a functional 
relation.  For  security  it  will  be  necessary 
to  demonstrate  that  each  executor  has  at  any 
single  time  exactly  one  clearance.) 
cJU  c f U M x C the  classification  relation.  (Similar  to 

cJOi  above,  it  relates  each  file  or  mailbox  to 
a set  of  security  classes  which  it  may  have 
at  different  times.) 
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In  addition  to  the  foregoing  sets  and  relations  which  are  static 
throughout  the  life  of  the  system  we  must  also  have  relations  which 
will  indicate  what  the  system  looks  like  in  each  state.  While  this 
could  be  described  by  a single  function  from  the  set  S into  a set  of  state 
values  each  of  which  would  be  a fairly  complex  substructure  we  prefer 
to  decompose  the  function  in  the  following  way: 


r :S  + P(E) 


T:S  - P(F) 

M:S  -*■  P(M) 

6:S 

+ P(F  X F) 

v-5 

■v  P{E  x F) 

a'- S 

P(E  x F) 

p":S 

-»•  PIE  x M) 

to.’  S 

->  P (E  x M) 

cjbuS 

-*  P (E  x C) 

.‘S  -*• 

P(FU  M X C) 

gives  the  subset  of  executors  which  exist 

in  each  state.  (Thus,  E (s)  is  the 

set  of  executors  in  the  system  during 

state  s.  We  shall  frequently  use  the 

notation  Es  for  the  set  E (s).  Note 

E - U E .) 

SeS 

gives  set  of  files  current  in  each  state. 
Again  we  shall  use  F$  to  denote  the  set  F(s). 

gives  the  set  of  mailboxes  in  each  state, 
gives  the  dominate  relation  in  each  state, 
gives  the  view  relation  in  each  state, 
gives  the  alter  relation  in  each  state, 
gives  the  block  relation  in  each  state, 
gives  the  wakeup  relation  in  each  state, 
gives  the  clearance  function  in  each  state, 
gives  the  classification  function  in  each 
state. 
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We  now  claim  we  have  a framework  in  which  state  changes  can  be 
effeciently  discussed.  Let  us  illustrate  this  claim  by  a simple  example. 
Suppose  there  is  an  S2-system  which  passes  through  the  following  states: 


In  "1"  there  is  one  executor  e and  one  file  f - no  security  classes 

in  this  example.  In  "2"  e has  been  connected  to  f for  viewing.  Then 

in  "3"  a new  file  g has  been  added,  and  finally  in  "4"  e has  been  dis- 
connected from  f.  Let  S = (S-|  be  a set  of  states  for  the 

system.  Then  F:S  -*•  P(F]  where  F = {f,g}  is  defined  so  that  F(S-|)  = { f } , 

F(S2)  = { f > , F(S2)  = {f,g}  and  F(S4)  = (f ,g } . Thus  T gives  all  infor- 
mation about  the  set  of  files  in  each  state.  ~ :S  P({e)  x F)  is  defined 
by  v(S-|)  = 7(S^)  = 0 and  7(S2)  = F(S2)  ={<  e,f>}.  Now  since  all  the  sets, 
relations  and  functions  are  static,  the  only  effect  of  a state  change  is 
that  the  "current"  state  changes.  Hence,  in  discussing  the  dynamic  be- 
havior of  the  system  we  need  only  be  concerned  with  the  set  S and  the 
transition  relation  x which  indicates  which  state  changes  can  occur. 

For  a given  s e S we  shall  define  the  10-tuple  <F(s),F(s],CT(s], 

F(s), v(s),a(s),g(s),u(s),c£*(s),c£A (s)>  to  be  an  S2-state  and  shall 
usually  write  it  as  <ES»FS»MS>  <$s,  W ^s,tiis,cl6s,cti>s>  or  even  as 
v,a,B,6,cM,dt6>s  . 

An  So- transition  is  an  ordered  pair  of  Sn-states  <<E  ,F  ,M  ,6  , 

c. r I S S S S 

Vs>as>  Bs,Ws,ciAs,c£6s>  <Et,^t,^t>-t,vt,at,  ^t'tot,c^/Lt,c^5t>>  suc*1 
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S X t. 


The  S^-state  gives  a complete  picture  of  the  condition  of  all  time- 
variant  elements  of  the  system  at  any  time.  We  note  that  each  S2~state 
has  a structure  similar  to  S-|  with  the  exception  of  the  set  of  security 
classes  and  its  accompanying  preordering.  We  make  use  of  the  similarity 
to  get  the  definition: 

An  S2~state  is  statically  secure  if  and  only  if  it  satisfies  the 
following  axioms: 


A2.1 

For  all  e e Es , f e Fs , e vs  f implies  cX&s (f )^s  c£*s(e). 

A2.2 

For  all  e E E$,  m E Ms,  e e$  m implies  cZ&s 'm)  = c£A$(e). 

A2.3 

For  all  e e Es,  f e Fs,  e as  f implies  ctn^ie)  < c£6s(f) 

A2.4 

For  all  e e Es>  m £ M$,  e ujs  m implies  c£>is(e)  <»  c£as(m) 

A2.5 

For  all  f £ Fs,  f 6S  f. 

A2.6 

For  all  f,  g e Fs,  f 6$  g and  g 6$  f implies  f * g. 

A2.7 

For  all  f,g,  h e F$ , f <5$  g and  g h implies  f <5g  h. 

A2.8 

For  all  f,g,  h e Fs , f <5S  g and  h 6$  g implies  f h or 

h 6S  f. 

A2.9 

For  all  e e Es , f , g e Fs , e vs  g and  f 6$  g implies 
e vs  f.  (That  is,  in  order  to  be  connected  for  viewing 
a file,  an  executor  must  be  connected  to  view  all  files 
which  dominate  it. ) 

A2.10 

For  all  e e Ej,  f,  g £ Fs,  e as  g and  f g and  f f g 

implies  e f.  (To  alter  a file,  an  executor  must  be 

connected  to  view  all  files  which  strictly  dominate  it.) 

A2.ll 

For  all  f,  g e Fj,  f 6 g implies  c£as(f)  ^ c£as  ( g). 
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Definition 


An  S2~transition  <s,t>  is  called  preserving  if  and  only 
if  s is  statically  secure  implies  t is  statically  se- 
cure. We  further  define  the  relation  x to  be  preserving 
if  and  only  if  for  all  s,  t e S,  s x t implies  <s,t>  is 
preserving.  Hence,  if  x is  preserving,  s is  statically 
secure  and  s x t,  then  t is  statically  secure. 

In  the  following  we  shall  be  concerned  with  the  security  preserving 
properties  of  sequences  of  transitions.  In  general  the  relation  x is 
not  transitive,  in  particular,  for  the  set  of  primitive  transitions  to 
be  introduced  later  it  is  not  true  that  the  composition  of  two  primi- 
tive transitions  is  a primitive  transition.  The  next  lemma  will  show 
that  compositions  of  preserving  transitions  are  preserving. 

Lemma  4.2.1:  If  x is  security  preserving,  s is  a statically  secure 

state,  and  s x*  t,  then  t is  a statically  secure  state. 

oo 

(x*  * U x11  is  the  transitive,  reflexive  closure  of  x.) 
n=0 

Proof:  (Using  induction)  Let  N be  the  set  of  natural  numbers, 

and  let  P(n)  be  the  property  "x11  is  preserving".  Then 
we  let  M = (M  e N | P(n)  is  true},  and  use  induction  to 
prove  M = N. 

First:  0 e M since  P(0)  holds  i.e.  x^  is  preserving 

because  s x^  t implies  s = t. 

Second:  suppose  N e M then  x11  is  preserving,  but 

xn+l  _ xn  o s xn+l  t anc|  s .js 

statically  secure  there  exists  a u e S such 
that  s Tn  u and  u T t.  By  inductive  hypothesis 
xn  is  preserving;  thus,  u is  statically  secure 
and  since  x itself  is  preserving  t is  also 
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statically  secure.  Hence  xn+“  is  preserving, 
P(n+1)  holds,  and  n+1  e M.  By  induction  N=M 
and  P(n)  holds  for  all  n,  or  xn  is  preserving 
for  all  n. 

★ 

Last:  Suppose  s is  statically  secure  and  s t t;  then, 

s xn  t for  some  n so  that  t is  statically 
secure.  B£S 


We  shall  say  that  a state  t is  reachable  from  a state  s if  and 
only  if  s x*  t.  Immediately  we  have: 

Corollary  4.2.1:  If  x is  preserving,  and  state  s is  statically  se- 

cure, then  every  state  reachable  from  s is  stati- 
cally secure. 


48 


4.3  An  Informal  Discussion  of  Some  Dynamic  Problems 


It  might  appear  that  this  last  result  gives  a sufficient  restric- 
tion on  the  transitions  to  ensure  a "secure"  S2;  however,  this  is  not 
the  case  as  is  shown  in  the  following  example.  Consider  the  system 
with  executors  {e^,e2}  and  files  f i > ^2*^3  security  classes 

{c.|  ,c2>Cg,c4,Cg,Cg } such  that  c-|  <_  c2  Cg,  c4  Cg  _<  Cg;  Cg  and  c^  are 
not  comparable.  Now  suppose  that  the  following  state  occurs: 


(e  |1  = Cg 

c&Mf^  « C] 
c&s(e2)  = c2 

CZ&{  fg]  = Cg 

cZMf3)  = Cg 


We  claim  this  "before"  state  is  statically  secure  because  e2  v 
implies  c£4(f-|)  c£A.(e2),  c-|  ^ c2  holds;  and  e2  tt  f2  implies 

ci^.(e 2)  £ c£&( f2),  c2  Cg  holds.  The  only  information  transfer  path 
is  from  f-|  to  f2,  and  this  does  not  allow  unauthorized  disclosure  since 
c£a(f^ ) < c£i(f2). 

Then  suppose  there  is  a transition  to  the  state: 

cJU(  ^ 1 * c5 

C-f 6 (f i ) = C-j 

cfAfe2  ) = c2 

c^(f2)  = c4  ** 

' Cg 
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We  claim  this  "after"  state  is  also  statically  secure  because 
e-j  a f3  implies  ciA.(e- 1)  ± c&s(f3),  Cg  ± Cg  holds;  and  e-j  y f2  implies 
cJU{ f3)  ± c£*.(e.|)  , 4 Cg  holds.  There  is  a transfer  path  from  f2 

to  f3  but  this  is  allowed  since  i.c£6(f3). 

Both  the  "before"  and  "after"  states  are  statically  secure,  the 
transition  is  preserving,  and  everything  seems  to  be  in  good  order. 

But  if  we  look  more  carefully  we  see  that  information  which  may  have 
been  transferred  from  f-j  to  f3  in  the  "before"  state  may  now  be  trans- 
ferred from  f^  to  f3  while  c£6(f-|)  is  not  comparable  with  c£a(f3). 
Although  both  states  are  statically  secure,  the  temporal  composition  con- 
tains an  information  transfer  path  from  f-|  to  f3  while  it  is  not  true 
that  cl6{ f^  ^ cti(f3). 

What  we  have  just  seen  is  an  example  of  a preserving  transition 
which  leads  to  a possible  non-secure  condition;  hence,  the  restriction 
to  preserving  transitions  is  not  sufficient  for  a system  which  is 
"dynamically  secure".  Before  we  attempt  to  further  qualify  the  transi- 
tions, we  need  a formal  definition  of  what  it  means  to  be  "secure". 

S-| -security  is  precisely  a formalization  of  security  which  prohibits 
unauthorized  disclosures  by  controlling  implicit  data  transfer  paths. 

We  will  be  satisfied  that  S2  is  secure  if  it  can  be  shown  to  be  an  ex- 
ample (or  valid  interpretation)  of  , and  this  is  the  next  step  in  our 
development,  that  is,  to  show  that  with  some  additional  restrictions  on  S9- 
transitions  we  get  a structure  which  is  S^-secure. 

We  need  a treatment  in  which  the  "dynamic"  data  transfer  path  in 
our  preceding  example  is  detected.  A fundamental  problem  is  that  file 
f2  in  the  example  forms  a link  in  two  different  information  transfer 
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paths > the  existence  of  which  depend  upon  two  different  states.  A 
possible  solution  is  to  flag  the  elements  in  the  two  states  so  that 
fb  in  the  "before"  state  is  logically  distinct  from  f®  in  the  "after" 
state > so  also  for  the  other  elements.  With  this  distinction  it  is  pos- 
sible to  picture  the  two  states  together  as  in  the  following  figure. 

c5 
C1 
c2 
c3 
c6 
c5 

C1 
c2 

c4 
c6 

Figure  4.3.1 

While  in  the  earlier  presentation  cZ&{ f^)  = c^  or  c^  depending  on 
state,  classification  is  now  a function  as  is  required  in  S-| . Files 
fij*  and  f?  are  incarnations  of  the  same  "real"  file.  From  what  we  know 
about  real  files  we  believe  that  any  information  stored  in  f,  will  remain 
in  it  through  the  transition  and  can  be  retrieved  from  f^.  But  since 
there  is  no  formal  connection  between  f^  and  f®,  additional  structure  is 
necessary.  A file  to  file  transfer  is  needed^ but  this  is  not  provided 
for  in  S-| , and  clearly  there  is  no  actual  transfer  of  data  since  fij*  and 
f®  are  merely  two  names  for  the  same  file. 
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Before  proposing  our  solution  let  us  digress  slightly  to  present 
a possible  alterative.  It  is  the  function  of  executors  to  transfer  in- 
formation; thus,  one  way  to  maintain  the  information  content  across  tran- 
sitions would  be  to  hypothesize  a new  class  of  agents,  perhaps  called 
quasi-executors,  whose  function  is  to  retrieve  information  from  files 
in  the  "before"  state  and  store  into  the  corresponding  file  in  the 
"after"  state.  The  file-to-file  transfer  logically  becomes  an  infor- 
mation transfer  path  which  can  be  handled  in  S-|  theory.  An  interesting 
result  is  that  if  we  require  quasi-executors  to  conform  to  the  normal 
classification/clearance  restrictions,  then  the  classification  of  a 
file  in  the  "after"  state  must  be  greater  than  or  equal  to  the  classi- 
fication of  its  counterpart  in  the  "before"  state.  Incidentally,  the 
failure  to  satisfy  this  requirement  is  the  source  of  the  insecurity  of 
the  previous  example.  The  quasi-agent  treatment  was  rejected  because 
it  also  leads  to  quasi-files  and  quasi-mail  boxes  and  it  appears  to  be 
rather  unnatural  or  nonintuitive.  We  now  return  to  the  mainline  of 
development  by  introducing  a device  which  if,  both  easier  to  formalize 
and  we  hope  more  natural . 

Refering  to  Fig. 4.3.1  we  note  that  if  executor  e^  alters  file  f^» 
the  effect  of  the  alteration  should  persist  in  file  f^  so  that  any 
executor  which  can  view  f^  should  thereby  be  able  to  "view"  the  effects 
of  the  alteration  of  e^.  The  resulting  principle  of  "persistence  of 
information"  will  be  generalized  to  imply  that  if  an  executor  can  al- 
ter a file,  then  since  the  alteration  persists  potentially  as  long  as 
the  file  exists  it  can  effectively  alter  every  subsequent  incarnation 
of  that  file.  This  principle  implies  that  classifications  of  files 
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must  increase  or  remain  constant  since  alteration  must  always  act  upon 
a file  of  equal  or  higher  security  class  than  that  of  the  acting  exe- 
cutor. 

On  the  other  hand,  e^'s  being  able  to  alter  f^  does  not  imply  that 
it  can  also  alter  f^  for  this  would  mean  that  an  executor  could  effect 
a change  in  a file  in  a state  which  no  longer  existed.  We  shall,  how- 
ever, permit  executors  to  carry  information  through  transitions.  Hence, 
in  the  example,  e^  can  alter  f^  in  ways  which  reflect  information  ac- 
quired in  state  "before"  by  e^.  In  this  manner  e^  can  alter  f^. 
This  may  sound  counterintuitive,  but  all  we  are  saying  is  that 
there  exists  the  possibility  of  transfer  of  information  from  e^  to  f^ 
without  an  intervening  file  or  executor. 

Similar  arguments  show  that  it  is  reasonable  to  assume  that  in  the 
case  of  the  view  relation  an  executor  cannot  view  a file  in  a future 
state-principle  of  "non  prescience  of  executors"  - but  can  in  effect 
view  files  in  past  states.  By  persistence  of  information,  once 
an  executor  has  "viewed"  a file  the  action  of  any  successor  of  that 
executor  may  reflect  the  viewed  information. 

Another  principle  is  that  if  an  executor  and  a file  do  not  both 
exist  in  at  least  one  common  state  there  can  be  no  direct  transfer  of 
information  (neither  view  nor  alter). 

In  Fig.  4.3.2  we  have  a representation  of  an  executor  e and  two 
files  f and  g which  exist  through  several  states.  The  horizontal 
transition  lines  can  be  thought  of  as  cutting  the  executor  into  a se- 
quence of  entities  each  of  which  carries  the  name  of  the  executor  it 
represents  and  the  name  of  the  state  in  which  it  occurs.  The  files 
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g v e ct  f 

State 


Figure  4.3.2 
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are  similarly  decomposed.  The  names  transient-file  and  transient-exe- 
cutor have  been  suggested  for  these  new  constructs.  If  we  suppose  that 
e is  connected  to  alter  f in  state  "4"  then  the  effect  of  possible  al- 
teration of  f will  persist  until  f is  deleted  after  state  "7".  Also, 
information  available  to  e in  states  "2"  and  "3"  may  be  transferred 
into  f.  Furthermore,  if  e is  also  connected  to  view  g in  state  "4", 
we  get  the  additional  direct  transfer  path  so  illustrated.  We  claim 
that  we  thus  include  all  possible  such  paths.  That  is  to  say  that  if 
information  moves  at  all  it  must  move  along  the  lines  shown.  This  pro- 
cedure will  be  formalized  later  after  some  additional  notation  has  been 
introduced.  For  now  let  us  review  the  example  of  Fig.  4.3.1. 

In  Fig.  4.3.3  the  "before-after"  picture  is  repeated  with  implied 
inter-state  relations  added.  We  now  see  that  there  is  an  information 
transfer  path  from  f^  to  fg  namely:  (f^,  e^,  f^>  e^,  fg)  (also  <f5j\ 
e2>  ^2’  ei*  ^3  *)•  And  since  it  is  not  true  that  c£a(fk)  < c£a(fg) 
we  better  not  be  able  to  show  that  such  a structure  is  an  example  of 
S-| . Clearly,  additional  restrictions  on  the  transitions  are  necessary. 
Although  the  explicit  view  relation  between  e^  and  fg  is  allowable,  the 
implied  view  between  e^  and  fg  should  be  prohibited  since  it  is  not 
true  that  c^Cf^)  «_  ciA-(e^).  After  all  this,  it  turns  out  that  it  is 
sufficient  to  require  that  if  classifications  (and  clearances)  change 
they  must  increase.  Thus  in  the  example  we  should  require  that 

or  else  not  permit  the  transition.  Of  course  under 
such  requirements  we  have  c£&(f  ?)  <i  ± 1 c£a(fga) 

and  we  are  in  good  shape.  We  will  next  show  that  by  generalizing  the 
preceding  arguments  we  can  show  that  all  possible  dynamic  information 
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transfer  paths  behave  in  proper  S-|  fashion. 


4.4  The  Dynamic  Security  of  $2 


Given  an  S2~structure  we  shall  by  the  following  construction  form 
an  associated  structure  of  transi ent-executors , transient-files  etc. 
in  which  each  S2  object  is  fragmented  into  logically  distinct  compo- 
nents in  each  state.  The  term  transient  is  used  to  indicate  the  transi- 
tory existence  of  the  new  object.  The  temporal  decomposition  is  accom- 
plished by  forming  for  each  object  in  Sg  the  cartesian  product  of  it- 
self and  the  set  of  states  in  which  it  exists.  While  some  of  the  rela- 
tions between  the  transient  objects  are  natural  and  straiqht-forward,  we 
shall  have  to  elaborate  upon  the  information  moving  relations  to  be  sure 
that  all  possible  S2  dynamic  information  transfer  paths  are  included. 


(4.4.1) 


(4.4.2) 

(4.4.3) 

(4.4.4) 


Eg  = (<e,s>|s  e S 


Fg  = {<f,s>|s  e S 
M £ = (<m,S> | s e S 


x 


and  e e Es>. 

We  begin  with  the  set  of  transient-executors 
thus,<e,s>  e Eg  means  that  e is  an  executor 
in  state  s.  Should  <e,t>  also  belong  to  Eg, 
then  e is  also  an  executor  in  state  t. 
and  fe  Fs> 

The  set  of  transient  files, 
and  m e Ms  \ 

Transient  mailboxes. 

is  the  dominates  relation  on  transient-files 
In  terms  of  the  S2  dominates  relation  it  is 
defined  by  <f,s>  <g,t>  if  and  only  if  s=t 

and  f 6S  t.  We  do  not  extend  the  dominates 
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relation  across  transitions.  Thus  we 
shall  not  allow  one  transient  file  to 
dominate  another  in  a different  state. 

(4.4.5)  ciAj,:  C is  the  clearance  function  defined  by  for 

all  <e,s>  e E cZ6^\<e, s>)  = c&>s(e). 

To  have  S-j -security  we  must  demonstrate 
that  it  is  indeed  a function.  But  this 
follows  from  the  definition  and  from  the 
fact  that  for  each  s e S,  cEa^.-E  + C is 
a function--part  of  the  requirement  for 
a statically  secure  state. 

(4.4.6)  cZdj.'F^  U -*■  C is  the  classification  function  defined  by 

for  all  <x,s>  e F^  u M , cE6^(<x,s>)  = 
c&ss(x), 

It  will  be  convenient  to  introduce  some  additional  notation  in 
the  form  of  a relation  defined  on  the  transient  objects  as  follows. 

For  all  <x,s>,  <y,t>  e Eg  u Fg  u we  shall  say  <x,s>  n <y,t> 
(i.e.  <x,s>  is  perpetuated  by  <y,t>)  if  and  only  if  x=y  and  s x t. 
Thus  a transient-file  <f,s>  <f,t>  is  perpetuated  by  a transient- 
file  if  there  is  a transition  from  s to  t,  and  f exists  both  in  states 
s and  t.  This  provides  a means  for  discussing  the  passing  along  of  in- 
formation from  transient-file  to  transient  file  and  also  for  transient- 
executors  and  transient-mailboxes. 

The  relations  view,  alter,  block  and  wakeup  must  be  constructed 
on  the  transient-objects  so  that  all  possible  information  transfer 
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paths  are  included.  A simple  example  was  given  in  sec.  4.3.  For  example, 
the  view  relation  must  encompass  all  direct  transfers  from  transient-files 
to  transient-executors.  By  "direct"  we  mean  the  information  does 
not  pass  through  any  intervening  file  or  executor;  thus,  we  see  that 
there  can  be  no  direct  transfer  unless  the  file  and  executor  coexist 
in  some  common  state.  Furthermore,  information  can  be  transferred  only 
if  in  that  common  state  the  executor  is  view  connected  to  the  file. 

We  formally  state  this  as  the 

Principle  of  Concurrency:  If  <e,s>  <f»t>,  then  there  must  be  a state 

u e S such  that  e e Eu,  f e Fu,  and  e vu  f. 

Note  the  notation  v^c  E^  x F^  for  the  trans- 
ient view  relation. 

We  also  have  the 

Principle  of  persistence  of  information:  we  assume  that  information  in 

a file  may  persist  as  long  as  the  file  exists; 
thus,  if  <e,s>  vs  s <f,u>  it  <f,t>, 

then  must  have  <e,s>  vg  <f,u>.  Furthermore, 
the  repeated  application  of  this  principle 
leads  to  a similar  statement  in  terms  of 

oo 

tt*  = u irn  the  transitive,  reflexive  closure 
n=0 

of  tt.  Finally  we  state  the 

Principle  of  nonprescience:  an  executor  cannot  perceive  (and  thus  pass 

on  or  make  decisions  on  the  basis  of)  information 
in  a file  before  the  transition  at  which  the  view 
connection  is  made.  We  are  saying  that  views  also 
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move  information  forward  in  time.  Similar 
arguments  apply  to  alter,  block  and  wakeup. 


On  the  basis  of  the  foregoing  we  make  the  following  defintion. 


vS-Esx  Fs 


the  transient  view  relation  defined  by 

O O 

(4.4.7)  <e,s>  <f,t>  if  and  only  if  there  exists 

u e S such  that  e e Eu>  f e Fu , e v f , and 
<f,t>  T7*  <f,u>  and  <e,u>  u*  <e,s>.  Thus 
for  information  to  be  transferred  from  f 
in  state  t to  e in  state  s it  is  necessary 
that  e and  f exist  in  state  u,  that  e vu  f 
and  that  state  u be  reachable  from  state  t 
and  state  s reachable  from  state  u. 

Similarly  for  other  relations  we  have: 


aS  - US 


Eo  x F, 


(4.4.8) 


- ES  X MS 


(4.4.9) 


W5  5 Es  x M< 


(4.4.10) 


the  transient  alter  relation  defined  by 
<e,s>  a,£  <f>t>  if  and  only  if  there  exists 
u c S such  that  e e Eu»  f e Fu»  e au  f,  and 
<f,u>  T7*<f,t>  and  <e,s>  77*  <e,u>. 
the  transient  block  relation  defined  by 
<e,s>  <m,t>  if  and  only  if  there  exists 

u e s such  that  e e eu»  m e Mu»  e gu  m,  and 
<m,t>  7r*<m,u>  and  <e,u>  77*  <e,s>. 
the  transient  wakeup  relationship  defined  by 
<e,s>  <m,t>  if  and  only  if  there  exists 

u e S such  that  e e Eu»  m E Mu»  e Wu  m,  and 
< m , u>  77 * < m , t>  and  < e , s>  77 e , u>  • 
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To  show  that  the  system  of  transient-objects  is  S-j-secure  we  will 
need  to  show  among  other  things  that: 

for  all  <e,s>  e E^,  and  <f,t>  £ , <e,s>  <f,t>  implies  that 

c£A5(<f,t>)  <.  cZns{<e, s>). 

The  proof  breaks  into  three  parts.  By  (4.4.7)  we  have  an  inter- 
mediate state  u in  which  e vu  f.  Now  if  we  restrict  the  set  of  states 
to  those  which  are  statically  secure,  u being  statically  secure  implies 
dU  (f)  ± cXa^ (e)  which  under  defintlons  (4.4.5)  and  (4.4.6)  yields 
cti^(<f,u>)  <_  ctn.^(<e»u>),  Secondly  if  we  can  be  sure  that  <f,t>Tr* 

<f,u>  implies  c£65(<f,t>)  < c£as(<f,u>)  and  that  <e,u>  tt*  <e,t>  implies 

c£A<,(<e,u>)  ^ c£^^(<e,t>)  and  thirdly,  if  we  know  * is  transitive,  then 

we  can  conclude  that  cX4s(<f,t>)  c£*s(<e,s>).  With  this  motivation 

we  make  the  following  definitions. 

An  S2  transition  <s,t>  is  permissible  if  and  only  if  it  is  pre- 
serving and  satisfies  the  following  axioms: 

A2.12  For  all  e e E.  e £ Esd  Et  implies  c£^s(e)  « clnt{e). 

(That  is  if  e exists  in  states  s and  t and  s T t, 
then  the  clearance  e can  only  increase  if  it  changes.) 

A2.13  For  all  f e F,  f e F$f)  Ft  implies  c£6s(f)  < c£it(f). 

A2.14  For  all  m e M,  m e M$n  Mt  implies  c£*s( m)  < cZit(m). 

(These  three  axioms  were  shown  to  be  necessary  in  the  examples), 
x is  permissible  if  and  only  if  for  all  s,  t £ sts  x t implies  <s,t> 
is  permissible. 


61 


An  $2-structure  (see  p.48)  will  be  called  S2~secure  or  dynamically 
secure  if  and  only  if  it  has  the  following  properties: 


1. 

x is  permissible. 

2. 

There  is  an  initial  state  Sq  in  S which  is  statically  secure. 

3. 

s e S implies  s is  reachable  from  Sq. 

(A2.15)  4. 

For  all  c e C,  c < c.  (_f  is  reflexive.) 

(A2.16)  5. 

For  all  c,d,e  e C,  c d and  d <e  implies  c <_  e. 
(<^  is  transitive). 

(A2.17)  6. 

For  all  f,  g e F,  s,  t £ S,  f <5$  g and  g e Ft  implies  f e 
and  f 6t  g,  which  states  that  while  a file  g exists  all  of 
the  files  which  dominate  g must  continue  to  exist  and  continue 
to  dominate  g. 

The  major  result  of  the  chapter  is  showing  that  the  system  of 
transient  objects  constructed  in  an  S2~secure  structure  is  an  example 
of  S-j.  The  resultant  properties  of  the  transients  allow  us  to  make 
assertions  about  information  transfer  paths  in  S2  itself.  Since  the 
transient-structure  lies  between  S-j  and  S2  it  might  well  be  called  ^ 
S1  g C,  ctg,  where 

the  components  are  as  defined  above. 

Proposition  4.4.1:  The  - structure  associated  with  an  S2-secure 


Proof: 

structure  is  an  -secure  structure. 

The  details  of  the  proof  are  given  in  Appendix  C. 

An  interpretation  of  the  basic  theorem  of  Sq  is  provable  in  S-j  5. 
Thus  we  have: 

Theorem  4.4.1:  In  an  ^structure  associated  with  an  S2  secure 

structure  if  there  is  an  information  transfer  path 
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from  transient-file  (or  mailbox)  <f,s>  to  transient- 


file  or  (mailbox)  <g,t>,  then  c£is(<f,s>)  <_  c£65(<9»t>) 
In  the  language  of  S£  this  can  be  stated  as 


Corollary  4.4.1: 

In  an  $2-secure  structure  if  there  is  a dynamic 
information  transfer  path  from  file  f in  state  s 
to  a file  g in  state  t,  then  the  classification  of 
f (in  state  s)  is  less  than  or  equal  to  the  classi- 
fication of  g (in  state  t). 

In  conclusion,  if  we  have  an  S2-structure  which  has  an  initial 
statically  secure  state,  and  if  we  allow  only  transitions  which  pre- 
serve static  security,  maintain  classification  from  state  to  state, 
then  there  will  be  no  implicit  information  transfers  which  could  lead 
to  unauthorized  disclosure. 
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5.  THE  SECURITY  EVENTS  IN  S3 
5.1  Introduction 

In  the  foregoing  chapter,  we  evolved  a set  of  axioms  which  are 
sufficient  to  ensure  a dynamically  secure  system.  The  S2-  structure 
is  described  as  a system  of  S-j-like  states  with  an  accompanying  set 
of  permissible  transitions  which  indicate  what  sequences  of  states 
may  be  allowed  in  a secure  system.  The  representation  is  highly  ab- 
stract in  that  files,  mailboxes,  and  executors  are  considered  to  be 
points  without  internal  structure.  However,  if  we  look  at  our  goal, 
a formal  specification  of  a Multics-like  system,  we  see  that  each  of 
these  elements  is  by  itself  quite  complex.  To  move  towards  this  more 
complex  representation,  we  will  now  present  a state  space  which  more 
accurately  depicts  the  real  target  system.  The  behavior  of  the  new 
system  will  be  formally  described  by  a set  of  security  events  or  ele- 
mentary operations.  After  the  events  have  been  presented  it  will  be 
shown  in  the  next  section  that  the  events  constitute  a set  of  permis- 
sible transitions  because  all  $2-axioms  are  satisfied. 

As  in  the  more  abstract  description  the  state  of  the  system  in- 
cludes the  sets  of  files,  mailboxes,  and  executors  which  are  current, 
their  classification  (or  clearance)  and  the  view,  alter,  block,  and 
wake  up  relations  in  effect  at  the  time.  Now,  the  classification  and 
status  (present  or  not)  of  a file  are  only  two  of  many  attributes.  A 
file  also  has  length,  location,  authorship,  and  so  forth.  To  the  extent 
that  these  secondary  attributes  can  be  changed  by  executors  and  those 
changes  perceived  by  other  executors,  they  must  be  considered  possible 
information  channels.  In  general  the  attributes  of  a file  will  be  kept 
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in  another  file  --  usually  the  dominating  file  in  the  file  hierarchy 
— so  that  the  information  will  be  naturally  protected  by  the  security 
mechanism. 

Since  we  cannot  hope  to  anticipate  all  conceivable  file  attributes, 
we  introduce  a new  set. 

I/p:  the  set  of  all  possible  file  attributes.  (These 

attributes  will  include  such  things  as  length,  con- 
tents, classification,  etc.) 

To  indicate  which  value  pertains  at  any  given  time  we  introduce  a 
time-variant  function. 

Fav:  F—M/p  is  the  file  attribute  function. 

A change  in  any  file  attribute  is  then  reflected  by  a change  in 
Fav.  Present  value  of  a particular  attribute,  such  as  classification, 
will  be  singled  out  by  a function  defined  on  t/p , such  as  cLi>:  1/p— ► C 
for  file  classification.  Thus  c£6(Fav(f))  would  give  the  value  of  the 
classification  attribute  of  file  f,  or  in  notation  of  Chapter  4 
ct6$(f)  = c£6(Fav(f))  where  s is  the  current  state.  In  this  chapter 
where  we  need  be  concerned  only  with  the  current  state  and  the  next 
state  (or  old  and  new  states)  we  shall  drop  state  subscripts  and  adopt 
the  convention  that  primes  indicate  next  state.  For  example  Fav(f)  = 
Fav' (f ) means  there  was  a change  to  a new  state,  but  the  file  attributes 
of  f remained  the  same. 

Similar  sets  and  functions  are  introduced  for  mailboxes  and  execu- 
tors. 

l/ij • the  set  of  possible  values  of  all  mailbox  attributes, 

(classification,  contents,  etc.) 
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Pa:  the  set  of  all  possible  values  which  all  the  properties 

of  an  executor  might  have.  (For  example,  clearance, 
priority,  etc.) 

Mav:  M — is  the  mailbox  attribute  value  function. 

E^:  E — * Pa  is  the  executors  property  function. 

There  are  also  several  functions  which  return  specific  properties  (or 
attributes  as  they  will  be  called  in  the  next  chapter). 

At:  l/p » {USED,  UNUSED}  is  the  "status"  function.  It  will  often 

be  used  in  conjunction  with  Fav  and  hence  we  define  the 
following  shorthand: 

ST:  F » {USED,  UNUSED}  and  is  equivalent  to  Fav  o At,  a composite 

function.  In  a similar  vein,  the  "classification"  func- 
tion : 

CLS:  F — >C  is  equivalent  to  Fav  o cJLa. 

CLP:  Ep — »C  the  "clearance"  function  is  equivalent  to  Fav  o cIa. 

Vat:  Pa * Info  the  "data"  function  returns  information  which  has 

been  obtained  by  the  executor. 

Con:  > Info  the  "contents"  function  returns  the  information 

held  by  the  specified  mailbox. 

In  the  following  section  we  shall  catalogue  the  security  events  in  the 
system. 
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5,2  Event  Descriptions 


El  Executor  £ becomes  view* connected  to  file  f. 

This  event  establishes  permission  for  executor  £ to  view  file  f_. 
However,  before  this  operation  is  allowed  to  have  any  effect,  certain 
conditions  must  hold. 

Cl .1  ST(f)  = USED. 

Tnat  is,  file  £ must  be  in  use  since  it  doesn't  make  sense  to 
connect  to  a nonexistant  file. 

Cl. 2 CLS{f)  < CLR(e) 

I 

The  clearance  of  the  executor  must  be  greater  than  or  equal  to 
the  classification  of  f. 

Cl .3  e v d 

File  f's  parent  must  be  view  connected  since  the  directory  hier- 
archy must  be  searched  in  order  to  find  f.  This  condition  is  suf- 
ficient to  guarantee  that  all  dominating  files  can  be  viewed. 

Now  we  must  assert  exactly  what  the  operation  does. 

Pl.l  ST' (f ) = ST(f ) 

The  file's  status  must  remain  USED. 

PI. 2 For  all  f1  in  F,  CLS'(f^)  = CLS(f, ) 

That  is,  the  classifications  of  all  files  are  unchanged. 

PI. 3 For  all  f]  in  F,  Fav'ff,)  = Fau(f1) 

All  other  file  attributes  remain  unchanged. 

PI.  4 For  all  e-j  in  E,  f-|  in  F,  e-j  6'  f-j  if  and  only  if  e-i  6 f ^ . 

In  other  words,  the  "dominates"  relation  remains  constant.  As 
will  be  seen,  only  the  "create"  and  "delete"  events  have  an  effect 
upon  6. 
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PI. 5 For  all  e-j  in  E,  f-j  in  F,  e-j  <*  f-j  if  and  only  if  e-|  a f|. 
The  "can-alter"  relation  is  unchanged,  i.e.  any  executor  can  alter 
exactly  those  files  which  it  could  alter  before  the  event. 

PI. 6 For  all  e-|  in  E,  f-|  in  F,  e-j  v'f-j  if  and  only  if  e-j  v f i 

OR  [e]  = e a f-j  = f aCI.1  a Cl. 2 A Cl. 3] 

That  is,  the  requested  addition  is  made  to  the  "can-view"  relation 
if  the  conditions  are  met.  Otherwse,  the  "can-view"  relation  is 
unchanged. 

PI. 7 For  all  m-|  in  M,  M-CLS'(m-|)  = M-CLS(m-|) 

All  mailboxes'  classifications  remain  the  same. 

PI. 8 For  all  m-|  in  M,  Mav'(mi)  = Mav(m-|) 

The  other  mailbox  attributes  are  also  unchanged. 

PI. 9 For  all  e-j  in  E,  m-j  in  M,  e-|  $'  m,  if  and  only  if  e-j  6 m-| . 
The  "can-block"  relation  is  unchanged. 

PI. 10  For  all  e-j  in  E,  m-j  in  M,  e-  a>'  m-|  if  and  only  if  e-|  u m-| . 
The  "can-wake"  relation  is  unchanged. 

PI. 11  For  all  e1  in  E,  CLR'  (e-j ) = CLR(e-j). 

The  executors'  clearances  do  not  change. 

Note:  it  will  be  seen  that  only  cne  event  - "Raise  Clearance" 

can  change  this  property. 

PI. 12  For  all  e]  in  E,  Eo'  (e-, ) = Ep(e-, ) - 

All  other  executor  properties  are  also  unchanged. 

As  can  readily  be  seen,  irost  properties  in  this  event  were  un- 
changed. For  the  remainder  of  this  chapter,  only  those  properties 
which  are  changed  by  the  event  in  question  will  be  listed.  However, 
the  properties  will  always  be  presented  in  the  same  order,  and  numbers 
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will  be  skipped  for  those  properties  not  discussed.  For  example, 
the  "can-wake"  relation  will  always  be  presented  as  property  Px.10, 
where  "x"  corresponds  to  the  event  number. 

E2  Executor  £ becomes  al ter-connected  to  file  f. 

The  second  event  is  similar  to  the  first  one  except  that  it  is 
the  "can-alter"  relation  which  is  changed. 

C2.1  ST(f)  - USED 
The  file  must  exist. 

C2.2  CLR(e)  « CLS(f) 

In  order  for  executor  £ to  be  able  to  alter  file  f_,  the  informa- 
tion-dissemination axiom  must  be  true;  that  is  the  file's  classi- 
fication must  be  greater  than  or  equal  to  the  executor's  clearance. 
C2.3  e v d 

That  is,  e^  must  be  able  to  view  file  c[  - (f's  parent  directory). 
Note:  this  condition  guarantees  that  the  directory  hierarchy  can 

be  searched. 

P2.5  For  all  e-j  in  E,  f-j  in  F,  e-|  a'  f-|  if  and  only  if  e-j  a f-| 

OR  [e1  = e a fi  = f a C2.1  a C2.2  a C2.3] 

If  the  conditions  are  all  satisfied,  the  requested  addition  is 
made  to  the  alter  relation,  otherwise  there  is  no  change. 

All  other  properties  remain  as  they  were  before  the  occurrence 
of  E2. 

Note  that  a file  can  become  "view  and  alter  connected"  if  both 
events  El  and  E2  occur  successfully.  As  we  have  shown,  any  serial 
combination  of  events  can  occur  consecutively  without  endangering 
security. 
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E3  Executor  £ becomes  disconnected  from  file  f. 

This  event  is  used  to  reverse  the  effects  of  the  two  previous 
events.  It  would  generally  occur  when  a user  logs  out  although  it 
might  also  be  invoked  in  the  middle  of  a run  to  protect  a data  file 
from  an  undebugged  program. 

C3.1  ST(f ) = USED 

P3.5  For  all  e-j  in  E,  f-|  in  F,  e-j  a'  f-j  if  and  only  if  e-|  a f-j 

a— i ((e1  = e)  A (f  « f-,)  a C3.1 ) 

In  other  words,  all  files  In  the  subtree  dominated  by  £ will  be 
"alter"  disconnected  from  executor  <e. 

P3.6  For  all  e-j  in  E,  f-j  in  F,  e-j  v*  f-|  if  and  only  if  e-,  v f-j 

a — , ((e-j  = e)  a (f  6 f^  a C3.1 ) . 

Similarly,  the  view  relation  is  changed  to  disallow  viewing  of 
file  f_  or  its  subtree  by  executor  e_. 

All  other  properties  are  unchanged. 
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E4  Executor  e_  creates  file  £ in  directory  d_  with  attribute  values 
V.and  classification  c. 

C4.1  ST(d)  = USED 

File  £'s  parent  directory  is  currently  in  use.  This  is  necessary 
to  guarantee  that  we  have  a tree  structure. 

C4.2  CLR (e)  < CLS[d) 

To  avoid  an  illegal  flow  of  information,  the  executor  must  be  at 
a clearance  which  is  less  than  or  equal  to  the  classification  of 
the  directory  since  creating  a file  includes  making  an  entry  in  the 
directory. 

C4.3  d 5 f and  for  all  f-j  in  F — i(d  6‘  f-j  a f-j  6'  f a f^  = d) 

File  £ is  in  directory  cL 
C4.4  ST(f ) = UNUSED. 

File  f is  not  currently  in  use. 

C4.5  CLS (d)  < C 

The  classification  specified  for  the  new  file  must  be  greater  than 
or  equal  to  d's  classification.  (This  is  a consequence  of  the 
tree-structure  axioms  of  S^). 

C4.6  a*(V)  = USED 

The  requested  value  for  status  must  be  "USED". 

P4.1  For  all  f1  in  F,  C4.1  a C4.2  a C4.3  a C4.4  a C4.5  a C4.6 

a f i = f implies  ST'  (f ) ^£(V)  while — i(C4.1  a C4.2  a 

a ...  A C4.6  A f1  = £ ) implies  ST'^)  = ST(f1). 

If  the  conditions  are  satisfied,  the  status  of  f becomes  "USED". 

CLS(f') ) if  — i(f  = f1  a C4.1 

a C4.2  a, . . a C4.6) 

c£a(V)  if  f f]  a C4.1  a ...  C4.6 


P4.2  For  all  ^ in  F,  CLS'  (fj)  = j 


71 


The  specified  classification  is  assigned  to  file  f if  the  condi- 
tions are  met.  Note  that  CLS(f)  (that  is  f's  classification  be- 
fore the  event)  is  undefined. 


P4.3  For  all  f^  in  F, 


Fav’  (f] ) - F^fl>  if  -^1  =f 

V if  f1  = f a C4.1  a . 


C4.1 


..  C4.6) 


/ C4.6 

Provided  that  the  conditions  are  satisfied  the  other  attributes 
are  assigned  as  designated. 

P4.4  a)  For  all  f -j , f£  in  F,  f-|  6'  f2  if  and  only  if  f-|  6 f£  OR 
(f 1 6 d a (f2  = f)  A C4.1  A ...  A C4.6)  OR 
((f-,  = f2  = f)  a C4.1  a ...  a C4.6) 
b)  For  all  f^  in  F,  f 6 f-j  f = f-| 

The  tree  structure  is  changed  to  include  f_.  Also,  f_  dominates  only 
itself. 

E5  Executor  ej  destroys  file  f_  in  directory  d_ 

This  event  allows  the  deletion  of  unwanted  segments  and  directories. 
Note  that  we  do  not  want  dangling  subtrees  due  to  A2.17.  Therefore,  if  we 
wish  to  delete  a directory,  we  insist  that  any  file  it  dominates  is  also 
deleted. 

C5.1  ST(d)  = USED.  The  parent  directory  must  be  in  use. 

C5.2  CLR(e)  < CLS(d) 

We  must  be  able  to  alter  d_,  since  the  directory  hierarchy  will  no 
lonaer  have  a pointer  to  f. 


P5.1  For  all  f-|  in  F, 


srtf^  » j 


UNUSED  if  f 6 f -j  a C5.1  a C5.2 


STtf^  if  -i(f«f|A  C5.1  a C5.2) 
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Given  that  the  conditions  are  satisfied,  the  file's  status  will 
become  "UNUSED". 


P5.2  For  all  f-j  in  F, 
CLS'  Cf -j ) - 


UNVEFINEV  if  f 5 f,  a C5.1  a C5.2 


CLS (f -j ) if — i(f  6 f1  a C5.1  a C5.2) 

The  file  destroyed  (and  any  descendants)  no  longer  has  any 
classification  defined  (assuming  of  course  that  the  conditions 
are  all  satisfied). 

P5.3  For  all  f-j  in  F, 

Fav'(f  ) = \UWEFINEV  if  f 6 f]  a C5.1  a C5.2 

Favff, ) if — i(f  6 f1  a C5.1  a C5.2) 

All  other  attributes  in  the  affected  files  will  now  be  undefined 
al  so. 


P5.4  For  all  f-j,  f£  in  F,  f-j  61  f2  if  and  only  if  f-|  6 f£ 
a — >(C5.1  a C5.2  a f 6 f-| ) 

For  all  files  that  remain  in  use  after  the  event  occurs,  the 
"dominates"  relation  still  holds.  Note  that  if  some  condition 
is  not  satisfied,  the  event  is  unsuccessful  and  no  change  is  made 
to  the  files  or  the  dominates  relation. 

P5.5  For  all  e-|  in  E,  f-|  in  F,  e-  a'  f-|  if  and  only  if  e-|  a f-j 
a — i(f  6 f1  a C5.1  a C5.2) 

Any  of  the  deleted  files  can  no  longer  be  altered.  Access 
remains  unchanged  if  the  event  is  unsuccessful. 

P5.6  For  all  f-,  in  F,  e-j  in  E,  e-j  v1  f-j  if  and  only  if  e-|  v f-j 
a — i (f  6 f,  a C5.1  a C5.2) 

If  the  conditions  are  met,  file  f_  and  any  of  its  ancestors  may  no 
longer  be  viewed. 
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All  other  properties  remain  uncharged. 


r 

E6  Executor  e_  changes  the  attributi  values  of  f_  to  V_. 

Most  of  the  state  changes  in  the  :ystem  will  involve  changing  the 
value  of  some  file  attribute  - usually  its  contents.  In  subsequent, 
more  detailed  models,  this  general  event  will  be  broken  into  a number 
of  more  specialized  operations.  Not  all  attribute  values  will  be  con- 
tained within  the  file  itself.  Some  w'  11  be  located  in  the  directory 
which  immediately  dominates  the  file,  ; nd  some  may  be  located  else- 
where. An  executor  will  have  to  have  ihe  proper  capability  to  access 
an  attribute.  As  a result,  additional  restraints  will  appear  in  the 
next  chapter.  For  the  present,  the  classifications  of  attributes  are 
ignored. 

C6.1  ST(f)  = USED 

The  file  must  be  in  use.  Otherwise,  it  would  make  no  sense  to 
change  its  attributes. 

C6.2  4*(V)  = USED 

The  file  remains  in  use  after  the  event  occurs. 

C6.3  cJU[\l)  = (f) 

The  classification  of  file  f also  must  not  change. 

P6.3  For  all  f-|  in  F, 

Fav1 (f)  = V if  fi  = f a C6.1  a C6.2  a C6.3 

< 

Fav  (f^  if  — »(f1  = f a C6.1  a C6.2  a C6.3) 
If  the  conditions  are  met,  file  f s attributes  are  changed  as 
requested.  All  other  properties  ire  unchanged. 
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E7:  Executor  e_  raises  classification  of  file  £ to  C. 

C7.  sr(f)  = USED 
The  file  must  be  in  use. 

C7.  For  all  f-j  in  F such  that  f 6 f-j , CLS(f ) ± C CLS(f-| ) 

The  new  classification  must  be  greater  than  or  equal  to  the  old 
one.  Furthermore,  the  new  classification  for  £must  be  less  than 
or  equal  to  that  of  any  file  which  £ dominates.  This  guarentees  that 
the  classifications  increase  as  you  get  further  from  the  root.  In  the 
next  chapter,  however,  we  will  see  that  a practical  implementation  will 
necessitate  an  even  more  constraining  condition  which  will  still  gua- 
rantee increasing  classifications  in  the  tree  (see  operation  10  in 
Section  6.8). 

P7.2  For  all  f]  in  ¥/ 

CLS 1 (f  ) — ^ if  'i  = f a C7 . 1 a C7. 2 a C7.3 

CLS(f-| ) if  — i(f-|  = f a C7.1  A C7.2  A C7.3) 

N 

File  f is  raised  to  the  new  classification  if  permitted.  All 
other  files  are  unchanged. 

P7.5  For  all  e-j  in  E,  f-j  in  F e-j  a'  f-.  if  and  only  if  e-|  a f-| 

a [ — i (f  6 fi  a f = f1  a C7.1  a C7.2  a C7.3)  OR 

C < CLR(erj )] 

The  "can-alter"  relation  may  have  to  be  changed  to  disallow  any 
file  whose  ancestor  is  f,  if  f can  no  longer  be  viewed  (see  next 
property). 

P7.6  For  all  e-j  in  E,  f-j  in  F,  e-j  v'  f-|  if  and  only  if  e-j  v f-| 

a [ — >(f  = f,  a C7.1  a C7.2  a C7.3)  OR 

C « CLR(e1)] 

In  order  for  some  executor,  e^  to  be  able  to  view  some  file  fy 
the  information  acquisition  axiom  must  be  satisfied,  that  is 
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CLS'(f.)  < CLR'(e.j).  If  the  new  classification  is  no  longer  less 
than  or  equal  to  executor  e,-'s  classification,  then  the  "can-view" 
relation  must  change.  Also,  if  f can  no  longer  be  viewed,  any 
file  dominated  by  f can  no  longer  be  viewed.  However,  the  condi- 
tions guarantee  that  these  dominated  files  could  not  have  been 
view-connected  before  the  event.  Therefore,  only  file  f need  be 
checked. 

All  other  properties  remain  unchanged. 


E8:  Executor  e views  file  f 


This  is  a passive  event,  in  the  sense  that  no  visible  changes  to 
the  state  occur.  We  do  however  define  a "contents"  function 
on  the  executor-properties  function.  This  might  correspond  to  some 
register  in  an  actual  machine  receiving  some  information. 

C8.1  e v f 


The  only  condition  necessary  is  that  executor  e is  able  to  view 
file  f. 


P8.12  VaX'  ( Ep(e) ) = 


f.  info  if  C8.1 
VcutUpie))  if — 1C8.I 

s 

If  allowed,  information  moves  from  file  to  executor. 


We  have  finished  describing  the  events  which  involve  files  and 
now  move  on  to  the  other  type  of  repository,  namely  mailboxes. 
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E9:  Executor  £ becomes  "receive-connected"  to  mailbox  m. 

This  event  allows  an  executor  to  receive  messages  from  (and  block 
on)  a mailbox. 

C9.1  CLS(m)  = CLR(e) 

Both  mailbox  and  executor  must  have  the  same  security  classifica- 
tion since  blocking  involves  both  a view  and  an  alter. 

P9.9  For  ail  e,  in  E,  m-|  in  M,  e-|  g'  m-|  if  and  only  if  e-j  g m-| 

OR  [e-|  = £ a m.j  = m a C9.1] 

If  permitted,  the  specified  mailbox  is  "block-connected". 

All  other  properties  are  unchanged. 

El 0:  Executor  e becomes  signal -connected  to  mailbox  m. 

CIO.  1 CLR(e)  < CLS(m) 

Executor  e_ must  be  allowed  to  alter  m and  hence  it  must  have  a lower 
security  class. 

P10.10  For  all  e-j  in  E,  m^  in  M,  e.j  oj ' m-j  if  and  only  if  e-|  to  m^ 

OR  [e-|  = e^  a m-|  = m a C10.1] 

The  "can-wake"  relation  now  includes  e can-wake  m if  the  condition 
has  been  satisfied. 

Ell:  Executor  £ becomes  disconnected  from  mailbox  m. 

P11.9  For  all  e:  in  F,  m-|  in  M,  e-j  B1  if  and  only  if 

e-j  e m-|  a (e^j  f je  v m-|  f m) 

PI  1 .10  For  all  e-j  in  F,  m-j  in  M,  u'  m^  if  and  only  if  e-j  o>  m-| 

(e-|  f e v m-|  f m) . 

Executor  e_  can  not  be  waked  via  the  disconnected  mailbox. 
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El  2: 


Executor  e_  raises  classification  of  mailbox  m to  £. 

Cl  2.1  M-CLS(m)  ^ £ 

A mailbox's  clearance  may  only  increase. 

C12.2  CLR(e)  « M-CLS(m) 

Since  the  classification  change  is  a modification,  it  must  be 
a writeup. 


P12.7  M-CLS'(m) 


C if  C12.1  a C12.2  a m-j  = m 

M-CLS(m)  if i(Cl 2. 1 a Cl 2.2  a m-j  = m) 


Mailbox  m acquires  the  new  classification. 

P12.9  For  all  e-  in  E,  m-j  in  M,  e-|  3'  m-|  if  and  only  if  e-|  3 m-j 
and  CLR1  (e-j ) = CLS'  (m-| ) 

The  "can  block"  relation  is  changed  so  that  m cannot  be  blocked 
upon  any  longer  (if  the  condition  is  satisfied)  since  the  classi- 
fication of  mailbox  is  no  longer  equal  to  the  clearance  of  any 
of  the  executors  which  previously  blocked  on  it. 


All  other  properties  are  unchanged. 


El 3:  Executor  e changes  the  attribute  values  of  m to  V. 

This  event  is  used  to  change  any  other  attributes  that  a mailbox 
might  have. 

C13.1  CLR(e)  £ M-CLS(m) . 

The  information  dissemination  axiom  must  be  obeyed. 

Cl  3.2  c£i(V)  = M-CLS(m) 

The  mailbox's  classification  must  not  change. 

P13.8  For  all  m-|  in  M, 
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El  4: 


Mav ' (m-j ) = f v if  - m a C13.1  a C13.2 

. Mau(m-| ) if — » (m-j  = m a Cl 3.1  a Cl 3. 2) 

All  other  properties  are  unchanged. 

Executor  e_  signals  via  mailbox  m 
An  actual  signal  is  sent  by  executor  e. 

C14.1  e to  m 

Executor  e can  signal  via  m. 

P14.8  For  all  m-j  in  M. 


Con’  (Mav  (m-| ))  = 


< 


Con(Mav  (m.| ))  u e. message  if  m-|  = m 
a C14.1 


Con  (Mav  (m-|))  if — i (m-,  = m a C14.1) 
A new  message  (in  addition  to  those  already  there  is  placed  in 
the  mailbox. 

All  other  properties  are  unchanged. 

El 5:  Executor  e blocks  on  mailbox  m. 

C15.1  e £ m 

Executor  e "can-block"  on  m. 

PI 5 . 8 For  all  m-j  in  M 


Con' (Mav(m-| ))  = 


Con(Mav(m-i  a — im-i  .message  if  m-,  = m a 
C15.1  1 


Con  (Mav  (m-j))  if — i(m-|  = hia  Cl  5.1) 
If  the  condition  is  satisfied,  a message  is  removed  from  the 
mailbox. 


All  other  properties  are  unchanged. 
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El  6: 


Executor  e raises  its  own  clearance  to  C. 


An  executor  may  raise  its  clearance,  however  we  must  make  sure 
that  its  capabilities  are  changed  to  be  compatible  with  the  new 
clearance. 


C16.1  CLR(e)  « C « MAXCLR(e) 


The  change  in  clearance  can  only  be  an  increase.  In  addition, 
the  new  clearance  must  be  less  than  or  equal  to  the  user's  clea- 
rance, i.e.  each  executor  has  a maximum  clearance. 

P16.5  For  all  e-j  in  E,  f-j  in  F,  e-j  a1  f-j  if  and  only  if  e-|  a f-| 
a [C  « CLS(f.,)  v — -C16.1] 


In  order  for  e_  to  continue  to  be  able  to  alter  a file,  the  file's 
classification  must  be  greater  than  or  equal  to  the  new  clearance. 
P16.9  For  all  e-j  in  E,  m-j  in  M,  e-j  3'  m-|  if  and  only  if  e-j  3 m-| 
a ,(e-|  = e a C16.1 ) 

Since  executors  can  block  only  on  mailboxes  at  the  same  classi- 
fication, all  presently  connected  mailboxes  must  be  disconnected, 
if  the  event  is  successful. 

PI 6. 10  For  all  m-|  in  M,  e-|  in  E,  e-|  w'  m-j  if  and  only  if  e^  w m-| 

a [ '(e-j  = e a C16.1)  OR  C < M -CLS(m1 )] 

If  the  condition  is  satisfied,  then  a mailbox  can  remain  signal 
connected  only  if  the  executor's  new  clearance  is  still  lower 
than  the  mailbox's  classification. 

PI 6. 11  For  all  e-j  in  E, 


CLRf  (e-j ) = , C lf  el  -A  C16,1 

CLR(e-| ) if  — i(e1  = e a C16.1) 

The  clearance  of  executor  e is  changed  as  specified  provided  that 
the  condition  is  met. 
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All  other  proportles  are  unchanged. 


El 7:  Executor  £ changes  its  properties  to  P. 

This  event  is  used  to  change  properties  other  than  "clearance" 
and  "user". 

C17.1  cJU(P) 

The  clearance  requested  must  be  the  same  as  the  present  clearance. 

C17.2  iuvi{  P)  = USER(e) 

The  executor  still  belongs  to  the  same  user. 

P17.13  For  all  e1  in  E 

'P  if  C17.1  a C17.2  a e1  = e 

EpCe^  if i(Cl 7. 1 a C17.2  a e1  = e) 

If  the  conditions  are  satisfied,  the  executor  acquires  a new  set 
of  properties. 

All  other  properties  remain  unchanged. 


Ep'^)  = ( 
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5.3  The  Connection  to  the  Previous  Specification 


Now  that  the  S3  specification  has  been  presented,  our  methodology 
requires  that  we  show  that  it  is  an  example  of  the  specification  pre- 
sented in  chapter  4,  and  hence  that  the  system  is  still  uncompromi sable. 
Specifically,  we  must  use  the  axioms  of  S3,  (primarily  the  conditions 
and  properties  which  accompany  the  various  events)  to  prove  that  the 
axioms  of  the  S2  specification  are  satisfied. 

Formally  this  requires  us  to  prove  seventeen  axioms  about  each  of 
the  seventeen  events  in  the  S3  specification.  This  would  be  a rather 
formidable  task  except  that  most  of  the  events  only  change  a few  parts 
of  the  state  of  the  system  and  most  axioms  at  S2  only  refer  to  a few 
portions  of  the  state.  Thus,  each  event  can  only  effect  a few  axioms. 
The  proofs  can  be  found  in  Appendix  D. 
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6. 


S4  - COMMANDS  AT  THE  SECURITY  PERIMETER 


6.1  Introduction 


In  the  previous  chapter,  we  presented  a set  of  prototype  operations 
for  the  Security  System.  These  prototypes  can  be  thought  of  as  equiva- 
lence classes  of  operations  (where  all  operations  belonging  to  the  same 
class  have  identical  security  considerations).  The  purpose  of  this  chap- 
ter is  to  describe  the  Security  Perimeter  - a group  of  primitives  which 
comprise  the  virtual  machine  seen  by  users  (and  the  operating  system). 

In  addition,  the  mapping  between  these  primitives  and  the  prototypes 
(of  the  last  chapter)  will  be  shown. 

At  this  point  in  the  specification,  it  is  necessary  to  introduce 
further  details  about  the  Security  System,  particularly  those  details 
concerning  the  properties  of  processes  and  files.  The  properties  of  a 
process  are  (for  the  most  part)  kept  in  the  Process  Segment  table,  while 
the  properties  of  a file  (its  attributes)  can  be  stored  within  the  file 
system  itself. 

One  file  attribute  which  is  of  particular  interest  from  the  military 
security  point  of  view  is  the  Access  Control  List  which  is  used  to  imple- 
ment "need- to- know"  security  restrictions.  Since  processes  can  only  ac- 
cess attached  files,  it  is  only  necessary  to  check  the  Access  Control  List 
attribute  when  performing  the  "GET  ACCESS"  operation  (see  operation  3 in 
section  6.8)  or  the  "REMOVE  rromACL"  operation  (see  operation  8). 
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6.2  Processes 


In  this  section  we  begin  to  introduce  some  of  the  structure  of 
user  processes;  and  in  particular  we  will  be  interested  in  the  follow- 
ing process  attributes. 

1)  the  user  to  whom  the  processor  beings 

2)  its  clearance  (security  class) 

3)  kinds  of  access  permitted  to  the  files  in  the  file  system; 
i.e.  read,  write  or  both. 

The  first  two  pieces  of  information  are  stable  in  the  sense  that 
the  amount  of  information  is  constant;  the  user  always  remains  the 
same  and  only  one  clearance  is  associated  with  a process  (though  it  can 
be  raised).  In  contrast,  access  information  can  change  in  several 
ways.  First,  the  type  of  access  to  files  can  change.  More  signifi- 
cantly, the  number  of  files  to  which  a process  has  access  can  change 
(thereby  changing  the  amount  of  information  about  a process).  To  keep 
track  of  its  access  rights  to  files  in  the  file  system,  each  process 
has  a table  called  the  process  segment  table  (PST). 
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6.3  The  PST 


The  Process  Segment  Table  is  a local  representation  of  the  file 
system  and  as  such,  it  contains  only  those  files  which  are  known  to 
the  process.  (See  Biba,  et.  al  [3])  However,  the  structure  of  the  PST 
must  clearly  be  related  to  that  of  the  file  system. 

PST  (conceptual)  PST  File  System 


Fig.  6.3.1  PST  Representation  of  the  File  System 

In  order  to  contain  sufficient  information  to  represent  the  struc- 
ture, each  PST  entry  contains  a pointer  to  its  parent  (in  the  PST)  and 
its  relative  position  or  entry-number  in  the  parent  directory.  At  first, 
one  might  suspect  that  a process'  PST  would  be  a subgraph  of  the  file 
system;  however,  in  order  to  reduce  the  amount  of  checking  which  must 
be  done  by  the  security  system,  we  do  not  insist  upon  it.  We  ensure 
only  that  there  is  a homomorphic  mapping  from  the  nodes  in  the  process 
segment  table  to  the  nodes  of  the  file  system.  In  other  words,  for  any 
node  in  the  PST,  there  is  only  one  node  in  the  File  System.  There  is 
however,  a possibility  that  two  or  more  nodes  in  the  PST  correspond  to 
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the  same  node  in  the  file  system. 

In  Fig.  6.3.1,  E-j  and  map  into  node  e.  More  will  be  said  about 
the  PST  in  the  section  about  operations.  In  particular,  we  will  show 
how  the  initiate  operation  allows  more  than  one  PST  entry  to  correspond 
to  a single  file.  It  is  also  possible  that  there  are  files  in  the  file 
system  which  are  unknown  by  a process;  i.e.  there  is  no  entry  in  the 
PST  corresponding  to  a node  in  the  File  System.  In  fig.  6.3.1,  files 
a and  c are  such  files. 

It  seems  appropriate  now,  to  give  some  insight  into  the  implementa- 
tion of  the  process  segment  table.  As  its  name  suggests,  the  PST  is  a 
table  whose  entries  represent  nodes  of  the  file  system.  Each  node  has 
an  implicit  name  - the  index  into  the  table.  Information  about  the  tree 
structure  of  the  PST  is  contained  in  links.  In  particular,  each  entry 
contains  a pointer  to  its  parent  in  the  PST.  Additional  information  in 
an  entry  would  include  the  entry-number  (as  explained  above),  a mapping 
to  the  file  system  (see  the  GET  ACCESS  operation),  an  indication  of  the 
type  of  file  (directory  or  segment)  and  whether  the  entry  is  in  fact  in 
use.  One  last  piece  of  information,  the  childcnt,  is  used  in  directory 
files  to  keep  track  of  the  number  of  attached  offspring  it  has.  This 
is  necessary  because  in  order  to  remove  ACCESS  from  a file,  it  must  not 
have  any  descendents  INUSE.  Fig.  6.3.2  summarizes  the  contents  of  a 
PST  entry. 

Parent  Link 

Ptr.  to  file  system 

Type/Inuse 

Entryno. 

Childcnt 

Fig.  6.3.2 
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6.4  Files 


Files  were  introduced  in  the  S-j  model  and  in  a sense,  they  are 
the  atomic  unit  in  the  information  storage  system.  As  in  the  case  of 
the  atom,  the  file  can  be  broken  into  smaller  pieces,  but  these  smaller 
pieces  (called  attributes)  have  no  function  by  themselves.  Just  as 
there  are  different  types  of  atoms,  there  are  different  types  of  files; 
in  particular  there  two  types  - directories  and  data-segments.  Data- 
segments,  represented  by  the  boxes  in  Fig.  6.3.1,  hold  the  information 
within  the  system  while  the  directories  provide  the  means  for  organiz- 
ing and  finding  this  information. 

Each  file  consists  of  a set  of  attiibutes  and  there  appear  to  be 
two  types  of  attributes  (which  should  be  considered  separately  for  spe- 
cification purposes).  The  first  type  consists  of  attributes  which  re- 
strict access  to  a file.  This  group  of  attributes  consists  of  CLS 
(classification),  ACL  (Access  Control  List),  TYPE  and  RINGBRACK.  The 
second  type  includes  CURLEN,  MAXLEN,  NAME,  DTM  (Date  & Time  Modified) 
etc.,  and  in  a sense  they  represent  physical  characteristics  of  the 
file.  The  important  difference  lies  in  the  fact  that  modifying  arbi- 
trarily one  of  the  access  attributes  could  have  disasterous  effects; 
e.g.  changing  CLS(f)  to  a lower  classification  would  be  equivalent  to 
moving  the  contents  of  f to  another  file  with  a lower  classification 
which  is  clearly  illegal. 

The  second  type  of  attribute  does  not  by  itself  pose  a security 
threat  (even  if  tampered  with)  however  the  attributes  must  be  given 
classifications  at  which  they  can  be  read  from  and  stored  into  when 
necessary  while  satisfying  the  Sq  axioms.  We  have  intuitively  decided 
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upon  the  classifications  of  these  attributes  (See  Ames  [1974])  and  later 
when  we  discuss  the  primitive  commands  of  the  system,  we  will  show  that 
there  are  no  violations  of  the  security  axioms. 

6.5  Access  Attributes 
CLS  (classification) 

This  attribute  indicates  the  security  level  of  the  file. 

A file's  classification  may  be  altered  by  three  different 
commands  - CREATE  FILE,  DELETE  FILE  and  RAISE  CLASS.  Each 
of  these  commands  must  allow  the  executor  to  view  and  alter 
the  file's  directory  and  hence  the  executor's  clearance  must 
be  the  same  as  the  classification  of  the  file's  directory. 
Since  the  executor  must  be  able  to  alter  "CLS",  it  must  be 
at  a clearance  less  than  or  equal  to  the  classification  of 
the  attribute.  Thus  the  classification  of  CLS  could  con- 
ceivably be  either  that  of  the  directory  or  that  of  the  da- 
ta segment.  There  is  however,  one  more  factor  which  con- 
trains  the  attribute's  classification:  The  RAISE  CLASS 

operation  must  check  that  the  new  classification  is  greater 
than  or  equal  to  the  old  one.  Since  it  must  view  CLS,  we 
stipulate  that  the  "CLS"  attribute  for  file  f_  has  a classi- 
fication which  equals  the  classification  of  d (file  f's 
parent  directory). 

ACL  (Access  Control  List) 

An  ACL  is  the  means  of  providing  discretionary  security.  By 
this,  we  mean  that  a user  A can  specify  who  may  have  access 
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privileges  to  any  of  his  files.  For  a user  to  access  such 
a file,  he  must  have  both  the  proper  clearance  and  A's  per- 
mission. Since  it  is  essential  that  a user  find  out  whether 
he  may  access  a file  f before  actually  accessing  the  file,  we 
stipulate  that  f's  ACL  is  associated  with  (and  at  the  same 
classification  as)  f's  parent  directory. 

TYPE 

Although  it  is  not  obvious,  this  attribute  also  serves  to 
restrict  access  to  a file.  A file's  type  may  be:  DIRECTORY, 
DATASEGMENT  0r  UNUSED.  If  a file's  TYPE  is  DIRECTORY,  or  UN- 
USED the  following  special  restrictions  are  placed  on  access 
privileges:  A directory  can  only  be  accessed  by  system  com- 

mands (for  integrity  reasons),  while  an  unused  file  just 
doesn't  exist  and  cannot  be  accessed  at  all.  A file's  type 
must  be  viewed  if  its  classification  is  to  be  changed.  Since 
it  must  be  viewed  and  altered  by  operations  working  at  the 
directory's  classification,  TYPE  must  also  be  at  that  clas- 
sification. 

RINGBRACKETS 

This  attribute  is  used  as  an  integrity  mechanism  in  Multics. 
Rlngbrackets  provide  the  means  for  restricting  the  access 
of  directories  to  ring-0  (privileged  system)  routines  and 
facilitate  a distributed  operating  system  whereby  another 
user's  interrupts  may  be  handled  without  switching  process- 
es. RINGBRACKETS  must  be  viewed  before  access  to  a file  is 
permitted  and  is  necessarily  at  the  directory's  classification. 
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6.6 


Characteristic  Attributes 


AUTHOR 

There  is  no  apparent  necessity  for  maintaining  this  attri- 
bute which  designates  the  user  who  originally  created  the 
file.  If  desired,  it  should  be  located  in  the  directory 
since  it  will  only  be  altered  upon  creation  and  deletion. 

BITCNT  (bit  count) 

This  attribute  specifies  (with  single  bit  granularity) 
how  much  of  a data-segment  is  being  used.  (It  is  not  appli- 
cable to  directories).  It  is  useful  for  printing  files 
etc.  but  is  ignored  by  the  security  system.  (It  is  some- 
what analogous  to  the  unofficial  clock  at  a football  game). 
The  attribute  must  be  at  the  same  classification  as  the 
data-segment  so  that  the  user  can  view  and  alter  it  while 
working  on  the  file.  We  use  the  terminology  "logically  lo- 
cated in  the  data-segment"  to  express  the  notion  that  con- 
ceptually, the  attribute  is  located  with  (and  at  the  same 
classification  as)  the  contents  of  the  file.  However,  it 
is  expected  that  in  the  actual  implementation,  this  attri- 
bute will  physically  reside  in  the  directory.  Still,  the 
use  of  system  routines  to  interperatively  access  items  in 
a directory  allows  the  system  to  "make  believe"  the  attri- 
bute is  really  in  the  data-segment;  that  is  it  will  obey 
the  security  restrictions  as  if  it  were  at  the  classifica- 
tion of  the  data-segment. 
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CURLEN  (current  length) 


This  attribute  is  an  integrity  mechanism  (though  not  the 
only  line  of  defense)  to  prevent  exceeding  a data-segment's 
boundary  and  illegally  accessing  another  file.  See 
Schroeder  and  Saltzer  [11  ] for  a discussion  of  how  Mul tics' 
virtual  memory  hardware  also  performs  this  function.  Since 
the  current  length  changes  as  the  file  is  altered,  it  must 
be  logically-located  in  the  file  itself.  (Refer  to  BITCNT 
for  a discussion  of  "logical-location").  Note:  this  differs 

from  the  present  Mul tics  Implementation. 

CONTENTS 

The  contents  attribute  (only  for  a data-segment)  is  the  in- 
formation which  is  kept  there.  Unlike  directories,  a data 
segment  may  be  filled  arbitrarily  and  directly  by  users  with 
appropriate  access  privileges  and  likewise  may  be  directly 
viewed  by  users.  The  contents  of  a file,  by  definition, 
reside  in  the  file  and  at  the  file's  classification. 

COPYSWITCH 

This  attribute  (used  only  for  data-segments)  assures  each 
user  his  own  copy  of  the  file.  This  is  necessary  for  seg- 
ments containing  non-reentrant  code.  The  user  need  not 
know  about  this  attribute,  however,  for  security  purposes, 
it  should  be  located  in  the  directory  so  that  it  may  be 
viewed  during  the  "GET  ACCESS"  command  which  operates  at 
the  directory's  classification. 


91 


DTD  (Date/Time  Dumped) 


This  attribute  is  used  by  the  file  system's  backup  mechanism. 
All  files  are  saved  regularly  so  that  restoration  can  be 
achieved  in  the  event  of  a system  failure.  Presumably,  some 
process  at  the  file's  clearance  must  view  the  file,  copy  it 
elsewhere  and  set  DTD.  Since  the  DTD  attribute  must  be  al- 
tered, it  should  be  logically-located  with  the  file. 

DTEM  (Date  and  Time  Entry  Modified) 

This  attribute  is  presently  used  in  Multics  to  indicate  when 
any  of  a file's  attributes  (besides  contents  of  a data-seg- 
ment)  was  last  changed.  Since  some  attributes  are  logical- 
ly-located with  the  file  itself,  while  others  are  logically- 
located  with  the  directory,  the  DTEM  would  have  to  be  logi- 
cally-located with  the  file.  Alternatively,  the  DTEM  could 
be  separated  into  two  attributes  - DTFEM  and  DTDEM.  The 
first  would  reflect  changes  to  attributes  logically-located 
with  the  file  while  the  second  would  represent  those  of  the 
directory.  Each  would  be  logically-located  with  the  attri- 
butes it  monitors. 

DTM  (Date/Time  Modified) 

This  is  similar  to  DTEM  (above)  but  is  modified  when  the 
contents  (of  a data-segment)  are  altered.  It  too  must  be 
logically  located  with  the  file. 
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DTU  (Date/Time  Used) 

In  present  Multics,  DTU  keeps  track  of  when  a file  has  been 
accessed  (in  any  manner).  It  is  useful  for  determining  the 
secondary  storage  medium  on  which  a file  should  be  kept. 

For  example,  a file  accessed  in  the  last  few  seconds  should 
probably  be  swapped  to  bulk  core  or  fast  drum  since  it  is 
likely  to  be  used  again,  while  a file  that  hasn't  been  re- 
ferenced in  several  months  might  be  moved  from  disk  to  tape 
in  order  to  save  disk  space.  Despite  its  usefulness,  DTU 
poses  a security  threat.  This  is  because  a file  may  be 
viewed  from  any  clearance  which  is  greater  than  the  classi- 
fication of  the  file.  Since  the  DTU  attribute  is  altered 
as  a result  of  this  observation,  it  must  be  at  a higher  clas- 
sification than  the  agent  which  viewed  the  file.  To  satisfy 
the  most  general  case,  it  cannot  be  stored  in  the  directory 
or  file  and  in  general,  it  cannot  be  viewed  by  the  owner  of 
the  file.  These  serious  restrictions  indicate  that  this 
attribute  should  be  maintained  within  the  security  system 
and  hidden  from  the  user.  For  alternative  schemes,  see  Biba, 
et.  al  [ 3]. 

IACL  (Initial  Access  Control  List) 

Specifying  an  ACL  each  time  a file  is  created  could  become 
annoying,  especially  if  the  ACL  is  complex.  Multics  has 
given  the  user  the  capability  of  specifying  a default  ACL 
known  as  the  Initial  Access  Control  List  or  IACL.  An  IACL 
is  associated  only  with  directory  files  and  stipulates  that 
all  files  created  in  it  (without  an  ACL  specified)  will  use 
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a copy  of  the  IACL  as  their  ACL.  Since  in  Multics,  the  IACL 
can  be  changed  by  anyone  with  modify  access  to  the  (directory) 
file  with  which  it  is  associated,  the  IACL  must  be  logically- 
located  in  the  (directory)  Itself. 

NAMES 

To  paraphrase  a famous  poem,  "A  file  with  any  other  name  would 
still  contain  the  same  information".  One  of  the  features  of 
Multics  is  that  a file  can  have  any  number  of  names  by  which 
users  can  refer  to  it.  In  order  to  simplify  the  security 
system  a file  is  accessed  as  an  index  into  the  Process  Seg- 
ment Table  (see  sec.  6.3).  However  for  convenience,  the 
operating  system  will  provide  users  with  reference  names  for 
the  file.  Since  the  NAMES  attribute  must  be  viewed  by  the 
operating  system's  "Delete"  command,  and  altered  by  the 
system's  "Create"  command  (both  of  which  occur  at  the  direc- 
tory's classification),  the  NAMES  attribute  must  be  logical- 
ly-located with  the  directory. 

QUOTA 

INFQCNT  (Inferior  Quota  Count) 

SPUSED  (Space  Used) 

TACCSW  (Terminal  Account  Switch) 

These  four  attributes  are  involved  with  the  file  system  quota 
mechanism.  As  the  name  implies,  quotas  are  used  to  limit 
secondary  storage  allocation.  Only  directories  may  have 
quotas  in  present  Multics,  and  not  all  directories  need 
quotas.  A file  attribute  called  the  Terminal  Account  Switch 
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(TACCSW)  determines  whether  the  directory  may  have  a quota. 
When  more  storage  space  is  needed  by  a file,  this  space  is 
charged  against  the  quota  of  the  first  directory  encountered 
(going  up  the  tree  towards  the  root)  which  has  its  TACCSW 
set  on.  (As  will  be  explained  later  in  more  detail,  this 
presents  a security  problem).  The  "Space  Used"  (SPUSED) 
attribute  indicates  the  amount  of  storage  charged  against 
the  quota  of  a directory.  The  difference  between  QUOTA 
and  SPUSED  gives  the  amount  cf  storage  space  that  may  still 
be  assigned. 

A security  problem  occurs  if  a user  is  writing  in  a data- 
segment  and  additional  space  becomes  necessary.  The  pro- 
cess must  be  capable  of  altering  the  file  and  of  viewing 
and  altering  the  QUOTA,  SPUSED  and  TACCSW  attributes  of 
some  superior  directory.  Clearly  the  process  would  have 
to  be  at  a clearance  equal  to  the  classification  of  the 
directory  file  which  contains  these  attributes,  and  unless 
blind  writing  of  the  data-segment  were  being  done,  the 
classification  of  the  segment  would  have  to  be  the  same. 

In  other  words  all  data-segments  would  have  to  have  their 
parent's  classification.  Alternatively,  data  segments 
could  be  given  their  own  quota  which  might  be  embodied  in 
the  MAXLEN  attribute.  SPUSED  would  then  be  taken  care  of 
by  CURLEW.  Clearly  the  space  usage  would  have  to  be  anti- 
cipated and  MAXLEN  set  ahead  of  time.  Also,  in  the  direc- 
tory structure,  TACCSW  would  have  to  be  set  at  each  direc- 
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tory  file  which  had  a classification  different  from  its 
parent's. 

One  restriction  still  necessary  is  that  quota  may  only  move 
down  the  tree  (away  from  the  root)  except  in  the  case  of  DE- 
STROY SUBTREE  (sea  sec.  6.8).  Quota  may  only  be  sent  down 
the  tree  - never  requested  and  it  may  only  be  taken  back  in 
its  entirety.  Thus  no  information  is  passed  downward  in  the 
form  of  a quota  request  or  encoded  in  a quota  return. 

RECUSED  (Records  Used) 

This  attribute  indicates  how  much  storage  space  is  used  by 
an  individual  file.  Since  RECUSED  must  be  modified  when  the 
file  is  modified,  it  must  be  logically-located  with  the  file. 
Thus,  RECUSED  may  only  be  observed  if  the  file  can  also  be 
observed;  it  may  not  be  observed  from  the  directory  containing 
the  file  as  is  the  case  with  the  present  Multics  implementation. 
SAFSW  (Safety  Switch) 

In  present  Multics,  the  SAFSW  attribute  is  used  as  a lock  to 
prevent  a file  from  being  deleted.  This  attribute  is  useless 
since  the  "Delete"  command  will  have  to  allow  blind  deletes. 

(See  Delete,  sec.  6.8) 

DID  (Device  Identifier) 

This  attribute  tells  what  type  of  storage  device  the  file  is 
stored  in.  It  would  have  to  be  at  the  classification  of  the 
file  itself  so  that  when  a file  is  moved  from  one  device  to 
another  the  DID  attribute  can  be  observed  and  modified.  Al- 
ternatively, this  attribute  could  be  hidden  from  the  user. 
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UID  (Unique  Identifier) 

The  purpose  of  the  UID  in  present  Multics  is  to  assure  that 
any  file  (possibly  accessed  by  more  than  one  name)  appears 
in  core  only  once.  Since  a file's  UID  may  not  change  (it  is 
view-only)  it  can  be  logically  located  with  the  directory. 

6-7  Process  Attributes 

Associated  with  any  process  will  be  three  basic  attributes:  Pro- 
cess Clearance  (PCLR),  Process  Segment  Table  (PST)  and  Process  User 
(PUSER).  These  attributes  will  be  described  here. 

PCLR  (Process  Clearance) 

This  attribute  gives  the  clearance  of  a process  (which  must 
be  at  a security  level  attainable  by  the  owner  of  the  pro- 
cess). Furthermore,  restrictions  must  be  made  on  how  a 
process'  clearance  can  change.  We  will  stipulate  that  it 
can  be  changed  only  by  the  "CHANGE  CLEARANCE"  operation 
(see  sec.  6.8)  and  the  clearance  can  only  increase. 

PUSER  (Process  User) 

A process  can  belong  to  exactly  one  user  and  that  user  will 
remain  the  same  throughout  the  life  of  the  process.  Hence 
the  PUSER  attribute  may  not  be  altered. 

Though  the  PST  is  an  attribute  of  a process,  it  is  both  unusual 
and  complex.  As  mentioned  before,  it  is  the  process'  "picture"  of  the 
file  system.  Each  known  file  will  have  at  least  one  PST  entry,  al- 
though some  redundancy  is  possible.  The  subentries  of  the  PST  will  be 
summarized  here. 
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ALPAR  (Alleged  Parent) 

When  an  entry  is  created  in  the  PST,  a pointer  indicating 
the  parent  is  created.  Since  no  information  about  this 
entry  (or  the  entry  pointed  to)  has  been  verified  with  the 
information  in  the  file  system,  we  use  the  term  "alleged 
parent".  As  long  as  the  PST  is  not  attached  to  some  file, 
information  in  the  entry  may  be  invalid. 

CHILDCNT  (Childcount) 

This  attribute  reflects  the  number  of  entries  which  have 
been  initiated  directly  inferior  to  this  entry.  It  is 
useful  in  making  sure  that  a directory  has  no  offspring 
still  attached  to  the  PST.  This  is  necessary  since  there 
are  no  downward  pointers  in  the  PST,  and  CHILDCNT  is  re- 
lied upon  to  determine  whether  a file  can  be  detached. 

ATTACHED 

To  be  of  any  use,  an  entry  in  the  PST  must  be  associated 
with  or  ATTACHED  to  some  file  in  the  file  system.  The 
ATTACHED  attribute  is  the  boolean  which  indicates  whether 
the  GET  ACCESS  operation  has  in  fact  taken  place.  When 
ATTACHED  is  true,  the  information  in  the  PST  can  be  re- 
garded as  being  accurate. 

MAP 

This  is  the  internal  pointer  in  the  PST  entry  which  pro- 
vides a handle  on  the  file  system.  It  can  be  used  only 
after  the  file  has  been  attached  and  is  set  up  during  the 
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GET  ACCESS  operation. 

PENTRYNO  (PST  Entry  Number) 

The  file  system  can  be  thought  of  as  an  ordered  tree  (see 
Knuth  vol . I,  sec.  2. 3. 4. 2)  since  the  order  of  the  branches 
is  Important.  As  a result,  any  file  can  be  uniquely  des- 
cribed by  two  pieces  of  information:  1)  its  parent  and 

2)  the  particular  branch  or  Entry  Number  within  the  parent 
directory.  Given  that  all  processes  are  attached  to  the 
root,  all  desired  files  can  be  described  by  working  down 
the  tree.  In  general,  the  ALPAR  and  PENTRYNO  attributes 
will  provide  enough  information  to  access  a file,  since 
PENTRYNO  corresponds  to  the  Entry  Number  of  the  desired 
file  within  its  parent  directory. 

6.8  Primitive  Operations 

We  are  now  ready  to  discuss  a set  of  primitive  operations  for  the 
system.  Our  goal  is  to  provide  a minimal  set  of  primitives  which  can 
be  certified  and  which  will  support  a Multics-like  system. 

Basically,  each  of  the  operations  manipulates  one  or  more  of  the 
previously  described  attributes.  By  placing  appropriate  restrictions 
on  critical  attributes  (those  listed  as  "Access  Attributes")  and  mak- 
ing sure  that  the  process  has  appropriate  access  permission  to  all 
attributes  used  to  carry  out  a primitive,  we  feel  that  a primitive  can 
be  certified. 

Before  jumping  into  the  descriptions  of  these  primitives,  a dis- 
cussion of  our  notation  might  be  helpful.  We  have  chosen  script  let- 
ters to  represent  functions,  e.g.  alpaA , type.,  kl.  They  return  the 
value  of  the  attribute  with  the  same  name.  Functions  beginning  with  a 
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capital  letter  return  several  values,  e.g.  l /£  (view-list)  which  re- 
turns a list  of  users.  Conversely  those  beginning  with  a small  letter 
return  a single  value  such  as  a file's  type  or  classification.  Com- 
posite functions  will  often  be  used  to  simplify  notation  and  will  be 
represented  by  capital  script  letters.  For  example  in  the  GET  ACCESS 
primitive,  while  attempting  to  attach  a PST  entry  to  some  file,  the 
TYPE  of  the  file  must  be  ascertained  by  the  composite  function: 
p-typz'(F)  = typz  [bsuindi  (vztvfayn  ? ( F ) , map  (alpar(F)))] 
using  shorthand,  we  will  write: 
p-typz'i F)  * TYPE ( f ) 

A function's  arguments  will  typically  consist  of  file  names  or 
PST  entries.  We  will  use  capital  arabic  letters  for  PST  entry  names 
though  the  reader  should  keep  in  mind  that  it  is  actually  an  index 
into  a table.  Files  will  be  represented  by  small  arabic  letters  though 

in  actuality,  files  can  only  be  referred  to  by  a pointer  (from  the  PST) 

to  the  file's  parent  directory  and  an  entry  number  within  the  direc- 
tory. For  our  descriptions,  the  letters  in  the  PST  will  match  those 

in  the  file  system  (see  fig.  6.3.1)  hovever  there  is  really  no  rela- 

tionship between  them. 

The  primitive  operations  will  be  described  in  terms  of  conditions 
and  properties.  A condition  will  have  a value  of  TRUE  or  FALSE,  while 
the  properties  will  represent  the  end  result  of  the  operation.  Note 
that  a property  may  depend  on  various  conditions  being  true. 

Each  of  the  properties  has  been  given  a number  for  organizational 
purposes.  The  descriptions  in  the  next  section  list  these  properties 
as  P x*n  where  x stands  for  the  operation  number  and  n represents  the 
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property  number.  Table  6.8.1  summarizes  the  properties  and  their  numbers: 


Px.l 

Cli 

(classition) 

Px.2 

ma.yvi.eu), 

mayalte/i  (These  correspond  to  discretionary  view  and 

alter  permission.  See  ADD  ACL,  and  the  6ETACCESS 
operations,  sec.  6.8.) 

Px.3 

type. 

Px.4 

Zing 

(ring  brackets) 

Px.5 

d-chan. 

(characteristics  or  attributes  logically 
located  in  the  directory) 

Px.6 

Z-chasi 

(attributes  logically  located  locally  or 
with  the  file). 

Px.7 

p-LL&e A 

(process'  user) 

Px.8 

p-  cin. 

(process'  clearance) 

Px.9 

p-type. 

(process'  type) 

Px.10 

dipa/c 

(alleged  parent) 

Px.ll 

chiZdcnt 

(childcount) 

Px.12 

attacked 

Px.  13 

map 

Px.14 

p-  entyno 

(entry  number) 

Table  6.8.1 

The  conditions  for  each  operation  are  also  assigned  numbers  which 
begin  with  the  letter  "C",  however,  the  number  has  no  implicit  meaning. 

One  additional  piece  of  information  is  given  to  indicate  the  ac- 
cess privileges  needed  to  test  a condition  or  satisfy  a property.  It 
is  located  near  the  right  margin  in  parenthesis  and  has  the  form 
(p  y PST)  or  (p  0 f)  etc.  where  0 and  y stand  for  observe  and  modify 
respectively  while  "PST"  or  "f"  indicate  the  repository  being  accessed. 
The  "p"  indicates  that  the  process  is  making  the  access.  Also,  "No 
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access  required"  is  indicated  by  a hyphen,  i.e.  (-). 

1 . ) INITIATE  PST  entry  £ as  entry  number  eno  in  £ with  type  J_ 

The  INITIATE  operation  is  used  to  place  an  entry  in  the  Process 
Segment  Table.  In  keeping  with  the  Multics  philosophy  that  a file 
doesn't  become  attached  until  it  is  accessed,  INITIATE  does  no  more 
than  build  the  entry.  This  information  is  not  considered  valid  until 
the  GET  ACCESS  operation  has  attached  the  file. 

Cl.l  p-£ypz(F)  = UNUSED  (p  0 PST) 

First,  the  PST  entry  must  not  be  in  use  since  information  which  is 
presently  valid  would  be  destroyed. 


Since  we  are  initiating  a file  in  D,  we  must  be  certain  that  D is 
expected  to  be  a directory.  If  not,  the  modification  of  CHILDCNT 
(see  PI. 11)  would  be  invalid. 

PI. 1-6  There  are  no  changes  made  tc  the  file  system.  ( - ) 


The  USER  who  owns  the  process  cannot  be  changed.  One  assumption  which 
has  been  made  is  that  a PST  is  created  with  P-USER  correctly  established. 


The  clearance  of  the  process  remains  the  same.  Recall  that  only  one 
operation,  CHANGE  CLEARANCE,  is  able  to  change  a process'  clearance. 
Again,  it  is  assumed  that  a PST's  P-CLR  attribute  is  properly  initiated. 
PI.  10  VF^PST  cdbpv t* (F-, ) = |D  if  (F]  = F)  a Cl.l  a Cl. 2 


Cl.  2 p-£ypz{  D)  = DIRECTORY 


(p  0 PST) 


PI. 7 Vp-j  eP  p-UL&QA.'  (p-j ) = p-aAeA(p-|) 


( - ) 


PI. 8 Vp,  eP  p-dVi'  (p, ) = p-ci/l(p-|) 


( - ) 


) otherwise  (p  y PST) 
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The  process  sets  up  a pointer  to  the  PST  entry  it  thinks  is  the  de- 
sired parent,  (see  explanation  of  PST  sec.  6.3) 

PI. 11  VF^PST  chUdcnt'(Fi)  = [ 0 if  (F-j=F)  a Cl.l  a Cl. 2 

^duZdcnti? i ) otheriwse  (p  y PST) 
The  CHILDCNT  attribute  must  be  initialized  to  zero  reflecting  the 


fact  that  no  files  have  been  initiated  inferior  to  £. 

ckUdcyvt'i D)  = 'ckildcrvt  (D)  + 1 if  (F,=F)  a Cl.l  a Cl, 2 
< 

chUdcnt  (D)  otherwise  (p  y PST) 

The  CHILDCNT  attribute  of  D must  be  altered  to  reflect  the  fact  that 
a new  file  has  been  INITIATED  below  it. 

PI. 12  VF^PST  attached' (Ft  ) = J FALSE  if  (F^F)  a Cl.l  a Cl. 2 

attac/ied(F-| ) otherwise  (p  y PST) 

The  ATTACHED  attribute  is  made  TRUE  by  i.he  GETACCESS  operation  and 
must  be  FALSE  until  that  time. 

/ 

PI. 13  VF-i€ PST  map*  (F-i ) = NULL  if  (F,=F)  a Cl.l  a Cl. 2 (p  y PST) 

< 

map(F^)  otherwise 

The  MAP  attribute  is  the  process'  handle  on  the  file,  however  it  is 
not  considered  valid  until  the  file  has  been  attached. 

PI  .14  VF^e  PST  p -&n£fLynd[F-\ ) = eno  if  (F-|=F)  a Cl  .1  a Cl  .2 

p-e.ntA.yno  (K, ) otherwise  (p  y PST) 

The  Process  Entry  Number  is  set  to  specify  the  file  within  the  direc- 
tory (in  the  file  system)  which  is  desired. 

PI. 15  YFf  PST,  Vn  e N 

branch1  (map(F^ ) ,n)  = branch  (map  ^F-| ) ,n)  ( - ) 

This  property  states  that  the  structure  of  the  file  system  is  unchanged 
or,  more  specifically,  that  each  directory  file  keeps  the  same  files 
as  offspring. 
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2. ) TERMINATE  PST  entry  F. 


This  operation  can  be  thought  of  as  the  opposite  of  INITIATE.  Its 
purpose  is  to  remove  an  entry  from  the  PST.  However,  several  checks 
must  be  made  before  the  operation  occurs. 

C2.1  ckUdcnt{F)  = 0 (p  0 PST) 

The  file  must  have  no  files  initiated  beneath  it.  i.e.  it  must  be 
either  a directory  with  no  offspring  initiated  or  a datasegment  (which 
obeys  this  condition  by  definition). 

changed. 

( - ) 

( - ) 

:2.1  A (F-|=F) 

p-typd F.|)  otherwise  (p  y PST) 

The  purpose  of  this  operation  is  to  make  an  entry  available  (which 

amounts  to  setting  the  P-TYPE  attribute  to  UNUSED). 

/ 


P2.1-6 

No  file  attributes  are  changed. 

P2.7 

Vp-je  p-U&QA  ' (pi ) = p- 

u42a(  Pi ) 

P2.8 

p-cln.'  (p)  = p-cU( p) 

P2.9 

VF-jePST  p-type*{ F-j ) = 

^UNUSED  i 

P2.10 

VFi<rPST  alpaA'i?^)  = 

UNDEFINED  if  ( F-j =F ) A C2.1 

alpaA(F-\ ) otherwise 

(P  v PST) 

P2.ll 

VFiePST  chUdcnt'  (F] ) 

■J 

0 if  (F1=F)  A C2.1 

1 

| akltdant  (F^  otherwise 
/ 

(p  p PST) 

P2.12 

VFiePST  attached'^) 

<- 

FALSE  if  ( F-j =F ) A C2.1 

attached (F , ) otherwise 

(P  p PST) 

P2.13 

VFiePST  map'  ( F-j ) = J NULL 

if  (F1=F)  a C2.1 

| map  (F, ) otherwise 
1 

(P  p PST) 

P2.14 

VF^PST  p-e.ntA.c/no 1 (F-j ) = 

(r  NULL  if  (F-j=F)  A C2.1 

p-entA.yno  (F-j ) otherwise  (p  y PST) 
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These  attributes  are  all  set  to  some  "safe"  value.  Although  they 
could  just  as  well  be  "Don't  Care"  since  INITIATE  initializes  them, 
as  a precaution,  they  should  be  set  to  NULL. 

P2.15  YF-|ePST,  VneRJ  bsiandi'  (map (Pi ) n)  ( - ) 

= branch  (map  ( F ■] ) , n ) 

The  file  system  structure  is  not  changed. 
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3.)  GET  ACCESS  a for  F 

The  Purpose  of  this  operation  is  to  give  the  process  a handle  on 
the  file  system.  This  involves  checking  all  the  information  in  the  PST 
for  correctness  and  setting  the  ATTACHED  and  MAP  attributes  to  appro- 
priate values.  Actually,  the  ATTACHED  attribute  consists  of  three 
parts;  VIEW-ATTACHED,  ALTER-ATTACHED,  and  ATTACHED.  The  last  of  these 
indicates  that  the  file  is  attached  in  some  manner,  while  the  first  two 
describe  the  process'  capabilities  for  a given  file.  When  the  GET  ACCESS 
operator  has  successfully  occurred,  we  know  that  mandatory  security 
(classifications),  discretionary  security  (ACLs  - mayattoA)  and 

ringbrackets  have  been  checked.  In  appendix  E,  we  show  that  the  value 
of  the  "ATTACHED"  attributes  remains  consistent  with  the  security  axioms; 
in  otherwords  we  can  assume  that  we  do  indeed  have  the  access  capabilities 
specified  by  these  attributes. 

The  argument  specifies  the  privileges  desired  by  the  process  for 
file  F.  Formally  a_£  {view-desire,  alter-desire}.  Note  that  a^  has  been 
specified  during  the  initiate  operation  and  is  an  implied  argument. 

C3.1  vlew-attachzd(alpcui(f) ) = TRUE  (p  0 PST) 

For  this  operation  to  take  place,  the  parent  directory  for  F (in  the 
file  system)  must  be  viewed.  Note  that  this  is  equivalent  to: 
vZejM-cuttac.he.d(d)  = TRUE 

where  D is  F's  alleged  parent.  This  shortened  form  of  notation  will  be 
used  throughout  this  section  although  D is  not  specified  and  must  be 
ascertained  during  the  operation. 

C3.2  p-typ&(D)  = DIRECTORY  (p  0 PST) 

Since  D is  allegedly  F's  parent,  we  would  like  to  make  sure  that  D 
is  a directory. 
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C3.3  TYPE(f)  e {DATASEGMENT,  DIRECTORY}  (p  0 d) 

This  condition  is  necessary  to  make  sure  that  there  is  something  to 
which  this  PST  entry  can  be  attached. 

C3.4  [*Zng  <_  accteAbound  (f)  V -j  a. alter]  a 
\_ning  <_  caZiboand  (f)  V ~i  a. view] 


The  ring  bracket  accessing  requirements  must  be  met.  See  Organic,  [ 9 ] 
for  details  about  ring  brackets. 

P3.1-6  All  file  system  attributes  remain  unchanged.  ( - ) 

P3.7,8  p-LU,eA,p-cZA  remain  constant.  ( - ) 

P3.9  VF^ePST  p-typziF^)  = 'TVPF(f)  if  (F-,=F)  a C3.1  a... a C3.4 

< 


p-type.( F-|)  otherwise  (p  p PST,  p 0 d) 

\ 

The  P-TYPE  attribute  (in  the  PST  entry)  is  set  to  the  TYPE  attribute 
of  the  file  in  the  file  system. 

P3.10  VF^PST  aZpoJi'  (F-j ) = alpcn{ F] ) 

Since  this  function  was  used  to  locate  £ in  the  file  system,  it  is 
correct  by  definition  in  the  sense  that  £ is  some  specific  offspring 
of  ci,  £ is  the  corresponding  offspring  of  £ and  £ corresponds  to  (or 
maps  into)  d. 


P3.ll  VF^ePST  cJUZdcnt' (F-| ) = 


0 if  (FrF)  a C3.1  a...  a C3.4 


ckiZdcnt(F^)  otherewise  (p  p PST) 

N. 

A newly  attached  file  cannot  yet  have  ary  offspring  attached.  Note 
that  with  proper  restrictions  on  other  operations  (namely  INITIATE, 
TERMINATE  and  REMOVE  ACCESS)  we  could  have: 


VF^ePST  duZdcnt1  (F-|)  = chZZdcnt(F^ ) ( - ) 

P3.12  vZew-attachzd' (F})  = (a. view  a [VIEW -ACCESS (f ,u)| a 

(F,=F)  a C3.1  a ...  a C3.4  a (p  p PST) 

CLS(f-|)  ± p-cOi(p)]  v vd.eu)-cUZache.d(F^ ) (p  0 d,  PST) 
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This  property  will  give  a process  the  "can  view"  capability  if  per- 
mitted and  desired.  The  term,  "a. view"  is  a boolean  used  to  indicate 
that  "view  desire"  is  true.  Besides  satisfying  C3.1-3,  user  u_ must 
have  view  permission  in  file  Vs  Access  Control  List  (denoted  by  the 
function  l/I  EW-  ACC  ESS),  and  the  "information  acquisition"  property  con- 
cerning Security  Classifications  must  hold.  (See  ACL  attributes.  Section 
6.5). 

VF-|ePST  cuUeA-aXtackzd' ) = (a. alter  a (p  0 d,  PST) 

a (F.|=F)  a C3.1  a C3.2  a C3.3  a C3.4  a (p  y PST) 

[ ALTER- ACC ESS (f , u ) ] a [p- c£a(p)  4 CLS(f1)]) 

V alteA-cubta.chzd{F^) 


This  property  is  similar  to  the  previous  one,  except  that  it  gives 
"can  alter"  capability  to  the  PST.  Again  ACL  and  CLS  attributes  must 
be  checked. 

VF-jePST  attached' (F-| ) = [ TRUE  if  (F-|=F)  a C3.1  a C3.2  a C3.3  a C3.4 

a££ac/ied(F, ) otherwise  (p  y PST) 

Note  that  the  case  where  a file  is  attached  with  no  access  privileges 
is  taken  care  of. 


P3.13 


VF-je  PST,  map1  (F] ) = 


bA.anch[map(aX.paA( F-|),  p-e.ntnyno(F-\ )] 
if  (F-|=F)  a C3.1  a.. .a  C3.4 


< 


(p  9 c.PST) 


map(F-|)  otherwise  (p  y PST) 

The  purpose  of  this  property  is  to  give  the  PST  a handle  of  some  sort 
on  the  actual  file.  (In  the  implementation,  this  would  be  a secondary 
storage  address  or  pointer).  Note  that  both  the  entry  number  and  alleged 
parent  which  were  specified  in  the  INITIATE  operation  were  used  to  ac- 
complish this  operation,  and  there  is  an  automatic  correspondence  (as 
described  in  sec.  5.3)  between  the  PST  and  the  File  System  since  the 
attributes  P-ENTRYNO  and  ALPAR  cannot  be  tampered  with. 
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P3.14  VF^ePST,  p-en^iyno' (F-j ) = p-cn£siyno{ F-| ) ( - ) 

The  P-ENTRYNO  attribute  must  not  be  changed. 

P3.15  VF-|ePST,  Vnejj,  blanch.1  (map(F-| ) ,n)  = b/ianch( map( Fi ) ,n) 
There  is  no  change  to  the  file  system. 
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4.)  REMOVE  ACCESS  for  F 


The  purpose  of  this  operation  is  to  invalidate  an  entry  in  the 
PST.  It  might  be  called  upon  if  an  error  were  made,  the  process  ter- 
minated, space  in  the  PST  were  scarce  or  there  were  some  cost  involved 
maintaining  an  (unneeded)  PST  entry.  In  general,  we  would  like  this 
operation  to  place  us  in  a state  which  followed  the  INITIATE  operation 
but  preceeded  the  GET  ACCESS  primitive  for  file  F_. 

C4.1  cUtaM(f)  = TRUE  (p  0 PST) 

We  must  check  that  £ is  indeed  a valid  entry.  At  first  one  might  con- 
jecture that  no  checks  are  necessary  since  if  it  were  an  invalid  (un- 
attached) entry  before  the  operation,  it  would  still  be  invalid  after- 
wards. However,  as  indicated  by  the  next  condition,  we  want  to  keep 
the  CHILDCNT  attribute  accurate  (for  both  F_  and  £'s  alleged  parent) 
and  thus  we  must  do  checking. 

C4.2  dii£dc.rvt{ F)  = 0 (p  0 PST) 


As  noted  previously,  a file  can  be  detached  from  a process  only  if 
none  of  its  offspring  is  attached. 

P4.1-8  unchanged 

P4.9  VF-|ePST,  p-tf/pc1  (F-| ) = p-type.( F-j) 

Since  a TYPE  may  be  specified  by  the  INITIATE  operation  and  we  know 
that  it  is  presently  correct,  we  can  leave  it  as  is. 


P4.10  VF-jePST,  aZpaJi'  ( F-j ) = aZpcui(F^) 
This  also  is  specified  by  INITIATE. 

P4.12  VF^ePST,  v^i&w-cufXa.c.kzd'  (F-j ) = 


FALSE  if  ( F-j  =F ) (p  y PST) 

a C4.1  a C4.2 

v^iew- attached  (F-, ) otherwise 
^ * 
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VF-| ePST  aUeA- attached’  (F, ) = | FALSE  if  (F^F)  a C4.1aC4.2 


attacked1 (F^ ) = 


/ 


^alteJi-attached ( F-| ) otherwise 
FALSE  if  (F-|=F)  a C4.1  a C4.2 


attached  {F ) otherwise 

V * 

This  property  represents  the  operation's  purpose  - to  remove  access 
privileges  from  (i.e.  detach)  the  file. 


P4.13  VF^PST,  mop'( F] ) = NULL  if  (F]=F)  a C4.1  a C4.2 

^mapCF^)  otherwise 

The  handle  to  the  file  system  is  no  longer  valid. 

P4.14  VF-|ePST  p-en&iyno 1 (Fi ) = p-ent/iyno (F-| ) 

Since  this  is  specified  by  INITIATE,  it  must  remain  unchanged. 
P4.15  The  file  system  structure  is  unchanged. 


5.)  CREATE  file  f_  as  entry  eno  in  directory  with  attributes  V_ 

This  operation  causes  a new  file  to  come  into  existence  in  the 
file  system.  The  new  file  can  have  almost  an  arbitrary  set  of  attri- 
butes (with  the  exception  of  CLS  which  must  be  greater  than  or  equal 
to  c£i(d)  ). 

C5.1  view-attached(D)  = TRUE  (p  9 PST) 

Some  attributes  in  d^ must  be  examined  (e.g.  type(f)  ).  Hence, 
view  privilege  is  required. 

alten- attached  ( D)  = TRUE  (p  0 PST) 

The  operation  of  creating  a file  f_  involves  setting  of  attributes 
which  are  kept  in  cL 

C5.2  p-type{ D)  = DIRECTORY  (p  0 PST) 
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A file  can  be  created  only  in  a directory. 

C5.3  TVPE(f)  = UNUSED  (p  9 d) 

Only  one  file  can  occupy  any  given  entry  in  a directory.  This  condi- 
tion precludes  the  existence  of  such  a file  before  this  operation  is 
carried  out. 


C5.4  p-cL i(D)  < c£d(V)  (p  9 PST) 

Since  the  CLS  attribute  of  a file  must  be  greater  than  or  equal  to 
its  parent's  classification,  this  check  must  be  done. 


C5.5  &/pe(V]  e {DATASEGMENT,  DIRECTORY} 

A valid  type  must  be  requested. 

C5.6  singly)  1 ring  (p) 

In  present  Multics,  a process  may  not  create  a file  with  a ring  num- 
ber less  than  its  present  ring  number.  This  is  a restriction  to  prevent 
a Trojan  Horse  (see  Anderson  [10]). 

P5.1  Vf i eF,  CIS'  (f i ) = |cZ6(V)1f  f1  = bunch(d,eno)*  C5.1  a ...aC5.6 


J^CLS(f i ) otherwise  (p  y d) 

P5.2  Vf  i eF,  ACL'  (f.| ) = |ac£  (V)  if  f]  = bunch,  (d,eno)  a C5.1  a.  ..aC5.6 

|ACL(f ^ ) otherwise  (p  y d) 

*ti/pe(V)  if  f.|=6/uzttdi(d,eno) a C5.1  a...aC5.6 
TYPE(f i ) otherwise  (p  y d) 

singly)  if  f^=6-w.nc^(d,eno) a C5.1  a ...a  C5.6 
RINGS  (f i ) otherwise  (p  v d) 

d-chafi[\l)  if  f^  =bunch  (d,eno) 
a C 5 . 1 a ...  a C5.6 

V-CHAR  (f, ) otherwise  (p  y d) 

* 

Z-cIwl(\I)  if  f1  = 6^mc/i(d,eno)AC5.1  a. .a  C5.6 
L-CHAR(f^)  otherwise 


P5.3  Vf i eF,  TYPE' (f i ) = 


P5.4  Vf i eF,  RINGS' (f^ ) = 


P5.5  Vf^F,  V-CHAR1  (f.| ) = 


P5.6  Vf-|€  F,  L-CHAR1  (f^ ) = 
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The  attributes  for  £ are  set  if  the  conditions  are  met. 

P5.7-14  p-uAeA,  p-cZ6  and  the  PST  attributes  remain  untouched 
since  the  file  has  not  yet  been  initiated. 


P5.15  Vd'jeF,  VneAl,  branch'  (di  ,n)  = 


f if  d-|  = map(D)  a n=eno 
a C5. 1 a ...  a C5.6 

bfumzh{ d-| , n)  otherwise 
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6.)  DESTROY  SUBTREE  whose  root  is  F 


This  operation  is  used  to  delete  files  from  the  file  system.  A 
trivial  case  occurs  when  £ is  a data  segment  (the  subtree  consists  of 
a single  node).  Due  to  restrictions  involving  ring  brackets  and  quo- 
ta, this  is  in  general  the  only  permissable  way  to  delete  files. 

In  the  present  implementation  of  Multics,  a user  may  not  delete 
a file  with  a lower  ring  bracket.  Hov/ever  suppose  (as  illustrated  in 
fig.  6.8.1)  there  is  a subtree  of  files  which  increase  in  classifica- 
tion arid  decrease  in  ring  number.  Obviously,  the  process  cannot  view 
the  ring  attribute  for  file  h_.  Furthermore,  file  £,  which  dominates 
£ could  be  destroyed.  Thus  we  have  the  undesirable  possibility  of  a 
loose  subtree. 

Another  problem  is  the  return  of  quota  from  a more  classified 
directory  to  one  with  lower  classification.  As  noted  in  sec.  6.6, 
the  only  way  to  prevent  flow  of  information  is  to  return  the  full  quo- 
ta allotment. 

These  two  reasons  force  the  DESTROY  SUBTREE  operation  to  ignore 
ring  brackets.  Although  there  could  be  more  restricted  forms  of  this 
operation  under  favorable  circumstances  (e.g.  a subtree  at  a single 
classification  with  high  enough  ring  brackets)  the  operating  system 
could  itself  enforce  the  restrictions  by  walking  the  subtree  and  hence 
the  security  system  need  not  be  complicated  further. 

Although  this  operation  is  unaesthetic,  without  it,  a file  system 
with  more  than  one  classification  would  be  unworkable.  Various  other 
alternatives  were  explored  by  people  at  the  MITRE  Corp.  (See  Biba,  et.al, 
[ 3 ]) 
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Fig.  6.8.1  - Ring  brackets  could  not  be  checked  when  an  uncleared 

user  tried  to  DELETE  SUBTREE  with  root  d. 
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C6.1 


vZew-attache.d  (D)  = TRUE  (p  0 PST) 

aUzA-cuUjxcktd  (D)  = TRUE  (p  0 PST) 

The  directory  file  which  contains  the  root  of  the  subtree  must  be 
viewable  and  alterable. 

C6.2  p-typz  (D)  = DIRECT.  D must  be  a directory 


P6.1  Vf1  CLS'(f)  = 


UNDEFINED  if  C6.1  a C6.2 


VI 


blanch.  (map(F)) 


(p  \i  pa^.(f  1 ) ) 


CLS(f-j)  otherwise 

The  classifications  of  all  files  in  the  subtree  must  be  set  to  UNDE- 
FINED. Note  that  the  S-j  axioms  guarantee  that  all  files  f-j  which  are 
in  the  subtree  are  at  classifications  greater  than  or  equal  to  d^ and 
thus  may  be  altered. 


P6.2  Vf1ACL'(f1)  = 


UNDEFINED  if  C6.1  a C6.2  a 


(p  y poJi (f-j )) 


f-j  e bMftdi  (map(F)) 


P6.3 


UNDEFINED  if  C6.1  a C6.2  a 

* 


P6.4 


ACL  Cf i ) otherwise 
TYPE'  (f^  = ' 

J f-j  e blench  (map(F)) 

TYPE( f.  ) otherwise 

t ■ 

RINGS'  (f^  =7  UNDEFINED  if  C6.1  a C6.2a 

* 

“ f-j  e blanch  (map(F)) 

^ RINGS  (f^)  otherwise 


(p  v poA(f-,)) 


(p  y pai( f-|] 


P6.5  Vf}V-chaA'(  f])  = 


UNDEFINED  if  C6.1  a 
* 

f-i  e blanch  (map(F)l 


IPu  f-j) 


KVchai  (f-,) 

/ 


P6.6  Vf1  L-chai' [f})  = 


UNDEFINED  if  C6.1  a (py^) 

[.jN  s.t.  f ^blanch  (map(F),N)] 

L-c, Wi(f-|)  otherwise 
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tpuAed'  (L'cfuvilmap(D)))  = 0 


(p  y po/t(d)) 


All  other  attributes  in  the  subtree  are  set  to  UNDEFINED,  however, 
we  have  to  be  careful  about  QUOTA  since  it  must  move  back  up  the  tree. 
Actually,  it  is  the  SPUSED  (spaced  used)  attribute  that  is  affected 
and  as  shown  in  Section  6.6,  SPUSED  for  file  d^  can  be  set  to  zero 
without  transferring  any  information. 

P6.7-8  Unchanged 

Clearly,  all  processes  which  are  ATTACHED  to  any  of  the  files 
in  the  subtree  must  be  TERMINATED.  One  thing  that  must  be  demon- 
strated is  that  having  the  Security  Kernel  detach  all  processes 
attached  to  the  tree  does  not  result  in  a downward  flow  of  information. 

Clearly,  any  process  p^ , attached  to  some  file  in  the  subtree 
with  root  F must  be  at  a clearance  greater  than  or  equal  to  the  clas- 
sification of  D;  i.e.,  CLS(D)  <*  p-cXr.(p.|).  This  is  a result  of  the 
fact  that 

map(F)  6 map(F^) 

that  is  F.|  is  in  the  subtree. 

Therefore: 


map(D)  = mapialpaj i(F))  6 ma.p(atpaA(F^ ) ) 

CLS(D)  < CiS(alpcUL( F, )) 

where  D is  F's  parent. 

Also: 

CLS  (a£pcw.(F-j ) ) < p-cX^p-j ) 

that  is,  p-|  must  be  able  to  view  F^s  parent.  In  order  for  p to 
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perform  "DESTROY  SUBTREE  whose  root  is  it  must  be  able  to  view 
and  alter  D,  hence  p-ei/t.(p)  = CLS(d). 

Combining  these  restrictions,  we  have: 


p-cU(p)  = CLS(D)  < CLS(o£po.'i(F1))  < p-cUip^ 

Thus  changes  to  another  process'  PST  will  not  result  in  a security 
compromise. 


P6.9  VF^PST,  p-ttjpz'  (F] ) = 


UNDEFINED  if  C6.1aC6.2a 
* 

map(F, ) e bAjCLndi  (map(F)) 


(p  v PST) 


_p-typt( F-| ) otherwise 


P6.10 


VF^PST,  alpax'  (F] ) = 


'UNDEFINED  if  C6.1aC6.2a 

* 

I map  (F-j)  e bsuindi  (map(F)) 

(p  u PST) 

^alpaA( F-j ) otherwise 


P6.ll 


UNDEFINED  if  C6.1aC6.2a 


VF^PST,  ckHdcnt'  (F-, ) = 


* 

^ a map(F^)  e bfia.nd> i (map(Fj) 

(p  v PST) 


cklldcyvt( F^ ) otherwise 
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P6.12  V F-j  ePST , attached'  (F., ) = < 


UNDEFINED  if  C6.1aC6.2a 
map(F^)  e branch  (map(F)) 

(p  v PST) 
. attachcd{?^ ) otherwise 


F^ePST,  view- attacked'  (F-j ) iff  view- attacked ( F-| ) 


a attacked'  (F^ ) 


F-jcPST,  aZten.- attacked'  (F^ ) iff  atteA- attacked{? ) 
a attacked’  (F^ ) 


P6.13  V F^ePST,  map' (F] ) =< 


UNDEFINED  if  C6.1 

* 

map'(F,)  e bsuinc.fi  (map(F) 


(p  y PST) 


.map^F^)  otherwise 


P6.14  V F^ePST,  p-entyno’ ( F, ) 


= < 


'UNDEFINED  if  C6.1a 

* 

map ' ( F i ) e bAanck  (map(F)) 


(p  y PST) 


p-entyno (F-|)  otherwise 


All  of  the  process'  information  about  the  deleted  files  are  set 
to  UNDEFINED.  Actually,  this  isn't  necessary  as  long  as  the  attached 
attributes  become  false,  however,  it  is  an  additional  precaution  for 
reliability. 
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P6.15  Vfi eF »VneN» branch'  (f^  ,n)  = 

"UNDEFINED  If  f-|  e branch,  {map (F),N 
« a C6.1aC6.2  (p  y pa/i(f^) 

_ ivianch(f.,  ,n)  otherwise 

All  files  in  the  subtree  have  these  attributes  set  to  null. 

7.)  ADD  to  ACL  for  file  F[user  IK  with  permission  A^ (for  i = i,n)] 

This  operation  deals  with  the  discretionary  controls  for  a file. 

Using  this  operation,  one  or  more  users  with  view  and/or  alter  per- 
mission can  be  added  to  the  Access  Control  List  of  a file. 

C7.1  altdA-attach&diU)  = TRUE  (pePST) 

Since  d^  contains  file  £'s  ACL  attribute,  we  must  be  able  to  alter  ci. 

C7.2  p-typz( D)  = DIRECT  (pePST) 

Only  directories  can  contain  the  ACL  attribute. 

P7.1  Vf]  eF,  CLS'  (f] ) = CLS(f] ) ( - ) 

The  file's  classification  does  not  change. 

P7.2  W^eF,  mayview'  (ACL (U^  ,f i ) = mayv<.eu) (AC L (U  ■ ,f-| ) ) 

v [A^ .alter  a C7.1aC7.2]  (pud) 

If  desired,  view  permission  is  given  to  user  U.  for  file  f ^ . 

Vf^eF,  mxyalt&a'  (ACL(U^  ,f^ ) ) = mayal£&i(ACL(Uj  ,f^ )) 

v [A.  .alter  a C7.UC7.2]  (pud) 

Similarly,  alter  permission  can  be  given. 
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P7.3-14  No  change. 


8.)  REMOVE  from  ACL  for  file  £ [user  U_.  permission  for  i = 1 , n] 

The  REMOVE  ACL  operation  is  used  to  terminate  access  privileges  for  one 
or  move  users  to  the  specified  file. 

C8.1  vi ew-outtac.hzd.  (D)  = TRUE 

aZXeA- attacked  (D)  = TRUE 

The  operation  requires  that  a file  be  checked  for  a given  user  and  the 
specified  access  and  that  it  be  changed. 

P8.1  VF-jePST,  CLS'  (F,)  * CLS  (F-| ) 

P8.2  Vf,eF  mayview'  ( AC L ( U ^ , f ) ) = mayV'Leiv[ACL[Uj ,f ) ) (p  p pan( f)) 
n i[A.j.view  a C8.1  a f,  = map(F)] 

Vf,eF  mayattoA'  (ACL (U^  ,f ) ) = mayaZteA{ACL[[).,f))  (p  p pa/i{ f)) 
n — i[A^.alterA  C8.1  a f,  = map  F] 

Changes  are  made  to  a file's  ACL  as  requested. 

P8.3-8  Unchanged. 

In  a manner  similar  to  that  used  for  DESTROY  SUBTREE,  various 
users  of  file  £ must  be  forcefully  detached  in  order  to  guarantee  that 
a user  can't  get  access  due  to  an  obsolete  capability. 

P8.9-11  Unchanged. 

P8.12  Vpi eP,  VF,ePST  p-j  vteu)- attached' (Fi ) = vteui-attachedpj  (F, ) 
n — i[A^.view  a C8.1  a (p-u4eA(p,  )eU.j ) a F,=F] 

(p  v PST,) 

Vp, ep,  VF-|ePST  p,  aJtten- attacked' p,  (F, ) = aiten- attacked? (F, ) 
n — ([A^. alter  a C8.1  a (p-ipje/i(Pi  )eU^ ) a F,=F] 

(p  p PST) 
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Vp-|eP,  VF-|ePST  p-, , attached' p-|(F-|)  = view- attached  'Pl(Fi) 
u alten.- attached ' p^  ( F-| ) 

All  processes  which  are  attached  to  file  F and  are  affected  by  the 
operation  are  changed  as  specified  above. 

P8.13  VF-| ePST,  V p^P,  map’p^F^  (p  y PST) 

_ map  P-j(F-|)  if  a^tacAed'p-|  (F^ ) 

' UNDEFINED  otherwise 

This  property  uses  the  same  conditions  as  the  "attached"  function  to 
determine  whether  there  is  a mapping  into  the  file  system. 

P8.14  Vp-jeP,  p-e.ntn.yno  ’ (p^ ) = p-entn.yno  (pi ) 

P8.15  VF-jePST,  VNeN  branch'  (map(F1 ) ,N)  (p  y PST) 

bnanc.h.[r,np[F-\  )»N)  if 
= S >[map(F^)  e hnanch* (map(F)) 

UNDEFINED  otherw  se 
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9.)  RAISE  CLEARANCE  to  C 


This  operation  allows  a process  to  raise  its  clearance.  It  is  impor- 
tant to  note  that  this  is  the  only  operation  which  may  do  that.  We 
have  made  (perhaps  unnecessarily)  the  assumption  that  a user  has  a 
maximum  clearance  that  cannot  be  exceeded  by  any  of  his  processes. 


C9.1 

A user  may  not 

p-ciA(p)  ^C^maxclA  (pa6CA(p)) 
exceed  his  highest  clearance. 

(p  9 PST) 

P9.1-6 

No  change  to  file  system. 

( - ) 

P9.7 

Vp-jeP  p-uaeV  (p-j ) = 

p-oaeA(p) 

( - ) 

P9.8 

VpeP  p-ota'  (p-j ) = 

< 

£ if  (p-|=p)  a C9.1 
p-cJUi[ Pi)  otherwise 

(p  v PST) 

The  clearance  is  set  as  specified. 


P9.12  VF-| , al^eAi- attached ' (F-j ) = (p  9 PST 

aLteA-cvtta.ckizd(F-\ ) a (C  £ p~c£a(F-|  ) ) ^ v 

v — i C9. 1 


The  new  clearance  must  be  less  than  or  equal  to  the  classification  of 
any  file  which  remains  alter-attached. 

P9.13.14  map,  p-entayno  are  unchanged. 

P9.15  branch  unchanged. 
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10.)  RAISE  CLASS  of  file  F to  C 

This  operation  is  used  to  raise  the  classification  of  a file.  As  will 
be  pointed  out,  there  are  several  restrictions  on  the  possible  classifi- 
cations for  files  in  a user's  subtree. 


The  process  must  be  able  to  view  and  alter  the  file's  directory.  Also, 
in  the  case  where  £ is  a directory,  £ must  be  viewable.  However,  fur- 
ther examination  of  this  condition  reveals  that  it  is  a serious  con- 
straint since  file  f and  its  parent,  d,  must  be  at  the  same  classification. 
Briefly,  this  is  because 

1)  the  process  p must  be  able  to  view  and  alter  file  d 
and  hence  CLR(p)  = CLS(d) 

2)  p must  view  file  f and  thus  CLS(f)  CLR(p) 

3)  and  finally,  the  tree  axioms  of  S,  force  the  clearances 

to  increase  going  away  from  the  root,  giving  CLS(d)  < CLS(f) 
Combining  all  this  information,  we  have: 

CLS{ f)  < CLR(p)  = CLS(d)  <CLS( f)  or  CLS(f)  = CLS(d) 

CIO. 2 VneW,  C_±clt>  (b/uinch(mp( F ) , n ) ) OR  p-typz[ F)  = DATASEG 
P10.1  VF^ePST  CLS'  (F-j ) = I C if  C10.1  a CIO. 2 a F^F 

£CLS ( F-j  ) otherwise 

The  classification  of  the  file  specified  is  changed  if  the  conditions 
are  met. 

PI  0. 2-1 1 Unchanged. 


Cl  0.1  vZojM-cuttadizd(D)  = TRUE 
aZteA-cUtachzd(D)  = TRUE 


(p  0 PST) 
(p  0 PST) 


p-typz{ F)  = DATASEG  OR  vxew-ottacAed(F)=TRUE  (p  0 PST) 


124 


P10.12 


Vp-jeP,  VFi ePST  \>leM)-attachedp^{F^)  = 

1 u-teic-aXtacKedpi  (F-| ) if  1 [C_  <_  p-cJt> 

| FALSE  otherwise 


(F)] 


Vp-jeP,  VF-jeF  alteA-ajtta.che.dp-i 1 (F-| ) = 
j alteA-atta.cke.dp]  (Fi ) if  vteu)- attached'  (D) 
1 FALSE  otherwise 


In  order  to  remain  alter  attached  all  ancestral  files  must  be  viewable 
(It  is  sufficient  to  show  that  the  parent  is  viewable). 

P10.13  VpieP,  VF1€F  map' p^F-j)  = 

I map'p^(F-j)  if  attached' p^iF^) 

[ NULL  otherwise 

The  "map"  function  has  the  same  constraints  as  the  " attached " function 
PI 0.1 4 p-entAyno  is  unchanged 

PI 0.1 5 baanch  is  unchanged. 
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7 


CONCLUSION 


7.1  Introduction 


We  have  demonstrated  the  use  of  a series  of  mathematical  struc- 
tures to  yield  the  specifications  of  a software  system  to  supply 
what  we  term  security  of  information.  The  use  of  this  technique  yields 
both  the  definition  of  the  global  properties  the  system  is  to  have 
and  the  local  assertions  which  must  be  proven  about  the  implementa- 
tion of  the  system.  This  technique  is  used  to  specify  a complete 
protection  system  so  that  mistakes  in  the  design  can  be  avoided.  The 
advantage  of  this  approach  is  that  the  assertions  are  obtained  before 
the  implementation  and  thus  can  be  used  as  a guide.  This  approach  is 
likely  to  result  in  a provable  implementation  since  the  proof  develop- 
ment can  proceed  concurrently  with  the  implementation. 
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7.2  Summary 


Chapter  2 presented  Sg,  the  first  in  a series  of  mathematical 
structures^ whose  purpose  is  to  give  a systematic  presentation  of  the 
specification  for  a secure  computing  system  based  on  military  require- 
ments. This  first  structure  defines  security  at  an  abstract  level. 
Since  it  is  devoid  of  actual  system  implementation  considerations, 
it  is  simple  enough  to  be  accepted  intuitively  as  a definition  of 
security.  A basic  security  theorem  was  then  proven  in  order  to  show 
the  design  of  the  structure  was  sound. 

Chapter  3 presented  structure  S-|  as  a refinement  of  the  original 
structure  Sg.  Structure  S-|  is  one  step  closer  to  specifying  an 
actual  system.  A tree  structured  file  system  and  a mailbox  mechanism 
for  interprocess  communication  were  introduced.  The  assumptions  about 
S-|  were  used  to  logically  determine  the  relationship  between  classifi- 
cations of  objects  and  their  positions  in  the  file  system  tree.  It 
was  then  shown  that  S-j  is  an  interpretation  of  Sg  by  proving  that  all 
theorems  true  in  Sg  were  also  true  in  S-|. 

Chapter  4 specified  a dynamic  structure  S2  to  describe  changes 
in  the  state  of  the  system.  With  proper  constraints  S2  was  shown  to 
be  an  example  of  an  S-|  structure  by  use  of  an  intermediate  structure 
SI. 5.  The  requirements  of  primitive  commands  changing  the  state  of 
a S2  system  were  specified  and  proved. 

Chapter  5 developed  a further  refinement  of  S2  as  Sg  to  allow 
specification  of  attributes  of  objects  in  the  structure.  Attributes 
were  logically  located  inS2  objects  for  the  purpose  of  security  but 
may  be  actually  implemented  differently.  A primitive  set  of 
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Mul tics-like  events  that  would  be  supported  by  a system  were  given 
together  with  the  assertions  and  proofs  necessary  for  security. 

Chapter  6 defined  and  outlined  proofs  of  commands  to  be  provided  by 
a secure  system.  These  commands  forming  provide  all  the  attributes 
and  operations  necessary  for  the  construction  of  a Multics-like  operating 
system. 
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7 . 3 Further  Work  to  be  Done 


Our  work  thus  far  has  shown  it  is  feasible  to  completely  specify 
a security  system.  S3  is  not  complete:  there  are  ways  yet  to  be 

specified  to  affect  and  observe  effects  on  the  system.  These  include 
billing,  input/output,  file  backup  and  recovery,  and  paging. 

7.3.1  More  Structures 

The  next  difficult  problem  is  not  the  addition  of  more  structures 
but  the  implementation  of  what  has  been  specified.  This  development 
process  would  then  become  structured  programming  and  we  would  be  con- 
cerned with  the  assertions  necessary  to  prove  the  implementation  cor- 
rect with  respect  to  the  assertions  given  by  the  previous  level  or 
the  last  structure. 

7.4  Other  Problems 

Construction  and  proof  of  a software  security  system  is  not  the 
entire  problem.  Ultimately  the  implementation  depends  on  the  hardware 
which  may  have  unforseen  affects  under  certain  conditions.  Accurate 
specifications  of  what  actually  happens  must  be  used  in  proofs  about 
the  implementation.  In  particular,  the  security  system  depends  on 
some  ad  hoc  integrity  mechanism  supplied  by  hardware  to  protect  it- 
self. This  mechanism  must  be  checked  to  make  sure  there  is  no  way 
in  which  it  can  be  bypassed  by  those  ojtside  the  security  system  or 
bypassed  by  incorrect  use  by  the  security  system. 

Second,  the  computer  must  be  physically  safe  from  external  tam- 
pering so  that  the  system  cannot  be  altered  and  its  communications 
lines  are  safe. 
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Another  problem  is  that  the  security  system  depends  on  correctly 
determining  the  privileges  of  a user.  Some  reliable  means  of  authen- 
ticating the  users  identity  or  determining  his  clearance  is  therefore 
necessary. 
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7.5  Future  Topics 


This  project  was  constrained  to  yield  a system  as  much  like 
Multics  as  possible.  The  attempt  was  to  secure  Multics  with  as  few 
changes  as  possible,  although  some  changes  not  visible  to  the  user 
were  made  in  order  to  make  the  system  smaller.  An  alternative  would 
be  to  design  a new  system  concentrating  on  minimizing  its  complexity 
and  thereby  making  the  proof  of  correctness  of  the  implementation 
more  managable. 

Another  extension  to  the  structures  could  allow  the  set  of 
classifications  to  vary.  Cur  current  design  which  assumes  a fixed 
set  of  classifications  is  suitable  for  individual  users  like  the 
Department  of  Defense  which  have  a permanent  set  of  classifications. 
However,  a computer  utility  needs  something  more  flexible  so  that  a 
customer  can  protect  his  information  from  other  customers  and  also 
control  security  between  his  various  projects. 

As  mentioned  previously,  implementation  would  use  an  ad  hoc  in- 
tegrity mechanism  to  protect  itself  from  external  interference.  The 
concept  of  integrity  could  be  formalized  and  combined  into  the  struc- 
tures to  yield  the  required  properties  of  a consistant  integrity  me- 
chanism. 

Another  use  of  structured  specification  could  be  to  formalize 
the  ideas  of  domains  and  capabilities  and  develop  the  required  pro- 
perties of  the  mechanisms  rather  than  simply  to  propose  various 
mechanisms  as  is  now  done.  Domains,  in  particular,  have  the  advantage 
of  partitioning  the  implementation  of  a security  and  integrity  system, 
simplifying  its  proof. 
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Appendix  A:  A General  Specification  for  Information  Passing 

Systems,  S_-| 

Last  moment  reflections  upon  the  overall  structure  of  the  sequence 
of  specifications  developed  in  this  report  led  to  the  discovery  that 
there  is  still  a more  primitive  underlying  conception  of  the  system 
than  even  the  Sg  specification  presents.  Its  existence  is  hinted  at 
by  the  "information  passing"  theorem  proved  in  Chapter  2. 

A.l  A Formal  Description  of  S ^ 

In  the  information  passing  specification  there  is  only  one  under- 
lying set: 

Ac  is  the  set  of  Accessories  to  information  passing. 

There  are  two  relations  involving  information  passing  between  accessories. 
a c_  Ac  x Ac  is  the  "allowed  to  pass  information"  retlation 
between  Accessories,  (x  a X means  that  accessory  x is 
allowed  to  pass  information  to  accessory  y) 
p c_  Ac  x Ac  is  the  "might  pass  information"  relation  between 
accessories,  (x^  p y. means  that  accessory  x has  some  pos- 
sible way  to  pass  information  to  accessory  y_.) 

There  are  three  axioms  in  this  specification,  and  the  first  two  reflect 
obvious  facts  about  possible  information  passing. 

A-l.l  (reflexivity) : For  x e Ac,  x p x.  (Accessory  x_ may  remember 

information  that  it  already  knows). 

A-1.2  (transitivity):  For  ar.y  >^,  y^  z_  € Ac,  if  x.  p y.  and  y.  p 2_,  then 

x p z.  (If  accessory  x^ might  pass  information 
to  accessory  y^  and  y^  in  turn  might  pass  infor- 
mation to  accessory  then  we  must  take  into 
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account  the  possibility  that  x_ may  be  passing 
information  to  z. ) 

The  third  axiom  connects  possibility  with  permission. 

A-1.3  (conformity):  For  x_,  e Ac,  x_  p ^=*x_  a (It  should  only 

be  possible  for  accessory  x_  to  pass  information 
to  accessory  if  x is  allowed  to  pass  informa- 
tion to  y_. ) 

This  last  axiom  is  perhaps  most  perspicuously  stated  in  contrapositive 
form: 

Corollary:  If  accessory  x^  is  not  allowed  to  pass  information  to  ac- 

cessory then  there  must  be  no  way  for  _x  to  pass  in- 
formation to  y_. 

The  "might  pass  information"  relation  p in  this  specification  em- 
phasizes the  importance  in  subsequent  specifications  of  identifying  all 
possible  paths  by  which  information  might  pass  from  one  point  to  another. 
The  "allowed  to  pass  information"  relation  a will  be  specified  precisely 
by  the  Clearance/Classification  scheme  introduced  in  Sq. 

Our  next  task  is  to  show  how  the  S_-j  and  Sq  specifications  fit 
together. 

A. 2 Proving  That  Sq  is  a Possible  Interpretation  of  S , 

First  we  must  identify  the  set  Ac  end  the  relations  a and  p of  the 
S i specification  using  the  sets,  functions,  and  relations  of  the  Sq 
specification.  Recall  that  in  Sq  we  have:  a set  of  agents  A,  a set  of 
repositories  R,  a set  of  security  classes  C,  a "can  observe"  relation 
0,  a "can  modity"  relation  y,  an  "of  lower  security  class"  relation  <_ 
a clearance  function  CIa,  and  a classification  function  Cl&. 


135 


The  information  passing  accessories  are  clearly  the  agents  A and 


the  repositories  R.  So  we  let  Acg  = A u R. 

We  clearly  need  the  clearance  and  classification  functions  to 
define  the  "allowed  to  pass  information"  relation  a.  The  definition 
will  be  simpler  if  we  define  an  auxiliary  "Classing"  function 
Cl:  A u R C according  to  the  following  definition: 


Now  we  can  define  the  "allowed  to  pass  information"  relation  ctg  on  the 
accessories  Acg  by  x ag  y Cl[x)  ± Cl(y) . The  definition  of  the 
"might  pass  information"  relation  p must  involve  the  "observe"  and 
"modify"  relations  0 and  y in  Sq.  In  fact,  the  proper  definition  is 
most  easily  given  it  we  first  define  an  auxiliary  "information  can 
directly  transfer"  relation  t on  Acq  by 

x x y x e A and  y e R and  x y y or 


The  "might  pass  information"  relation  pg  is  just  the  reflexive,  transi- 
tive closure  t*  of  the  relation  t. 

To  show  that,  with  these  definitions,  Sq  is  a valid  interpretation 
of  the  S_-|  specification,  it  is  necessary  to  verify  that  the  three  S_, 
axioms  hold.  The  first  two  axioms  are  trivial  to  verify,  since  pg  is 
by  definition  the  reflexive,  transitive  closure  of  a relation  t- 
Theorem  1 (reflexity):  For  x.  e Acg,  x_  Pg  x. 

Theorem  2 (transitivity):  For  x,  z_  e Acg,  if  x_  Pg  y.  and  y_  pg  z 

then  x Pg  z. 


CIa(x)  if  x e A 

Cld(x)  if  x e R 


x e R and  y e A and  y 0 x 
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Verifying  the  third  axiom,  however,  requires  the  use  of  the  axioms 


of  S0. 

Theorem  3 (conformity): 

For  x,  x e Ac0,  if  x pg  x>  then  2L  cq  X 

Proof: 

The  result  is  obtained  by  showing  ^ is  a 
reflexive,  transitive  relation  which  in- 
cludes the  relation  x.  Since  x*  is  by 
definition  the  smallest  reflexive,  transi- 
tive relation  which  includes  the  relation 

Lemma  1 (reflexivity) : 

x,  x*  = pg  must  be  included  in  the  relation 
ag,  which  is  what  this  theorem  asserts. 

For  x e Acg,  x_  oig  x. 

Proof: 

C£(x)  C£(x),  since  ^ is  reflexive 

Lemma  2 (transitivity): 

x ag  x by  the  definition  of  ag. 

For  x , x»  z e Acg,  if  x ag  X and  x aQ  z, 
then  x ag  z. 

Proof: 

assume  x_  ag  X and  X °o  - 

C£ (x^)  ± C£(x)  by  definition  of  ag 

C£(y)  4 C£(z|  by  definition  of  aQ 

C£(x_)  C£(z)  by  the  transitivity  of  < 

* 

Lemma  3 (containment): 

x an  z by  the  definition  of  ag 

x£  aQ.  (That  is,  for  x,  x e Acg,  if  x x x» 
then  x a0  x) 

Proof: 

assume  x.  T X 

either  x^  e A and  e R and  x_  y X 
or  x e R and  x e A and  x 9 >L  by  defini- 

tion of  X. 
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Case  1 : 


by  the  dissemination 
axiom. 


x u x 

CU (x)  * Ch>{y) 

Cl[x)  <_Cl{y)  by  definition  of  Cl 
Case  2:  G x_ 

Cts(x)  <±ClA[y)  by  the  acquisition 
axiom 

C£(x)  C£(y)  by  definition  of  Cl 

CIM  <C£[y)  since  this  is  true  in  either 
case. 

£ ag  y_  by  definition  of  oiq. 

x x y=i>x  Oq  y as  desired 

The  Sq  specification  has  now  been  shown  to  be  an  example  of  the 
S_i  specification,  and,  by  our  general  methodology,  we  know  that  all 
subsequent  specifications  will  be  examples  of  Sq  and  hence  of  S_-| . 
Accordingly  we  know  that  all  of  our  specifications  will  carry  along 
this  basic,  very  simple  idea  that  information  must  not  go  where  it  is 
not  allowed  (by  regulation)  to  go. 
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Appendix  B:  Formal  Description  of  S-j  Consistency  and  the  S-|-Sq  Relationship 


This  appendix  contains  the  propositions  and  proofs  which  are  neces- 
sary to  establish  the  relationship  between  the  structures  S-|  and  Sq. 
PROPOSITION  3.1:  S.j  is  consistent. 

PROOF:  Consider  the  relational  structure  S-j ' consisting  of  the  set 

{a',  b',  c',  d 1 } with  relations  p'p  a'p  p'w,  a'w>  , s' 
defined  so  that  d'  </  d',  b'  6 b',  a'  a'F  b'  hold,  and  these 
are  the  only  relationships  which  hold,  and  functions  els' 
and  CZsi'  defined  so  that  C£s'(b')  = Cls'(c>)=CiA>  (a')=d*. 

Let  i denote  the  one-to-one  correspondence  between  the  set 
(a1,  b',  c',  d'}  and  any  subset  of  four  of  the  formal  object 
symbols  of  . Further  define  the  subsets  A,F,M,C  such  that: 

A = { i (a ' ) } , F = {i  (b ' ) } , M = Ti  (c ' ) } and  C = {i  (d ' ) }.  Also 
define  the  predicates  in  S-j ' so  that  for  x,  y e {a',  b1,  c',  d ' } , 


if  x p' F y 

then 

i (x) 

pf  i(y) 

If  x P'My 

then 

i(x) 

PM 

if  * o'  p y 

then 

1 (x) 

aF  i(y) 

if  x a'My 

then 

i (x) 

If  x V y 

then 

Kx) 

i 1 (y) 

if  x s'  y 

then 

1(x) 

t Ky) 

C£i(i (x) ) - 

i (Cls 1 

(x)) 

C£A(i(x))  = 

i(ce/L'(x)) 

It  will  now  be  shown  that  the  axioms  of  S-j  hold  true  in  S-j ' . 
Al.l  For  all  c e C,  c = i(d'),  but  d'  <_'  d'  in  S-j ' and  thus 

c < c . 
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A1.2  For  all  c,  d,  e e C,  c = d = e = i(d')  but  d'  d'  in  S-| 
and  thus  c _<  d and  d <_  e implies  i (d * ) <_  i (d1 ) or  c <_  e, 

A1.3  For  all  a e A,  f e F,  a = i(a')  and  f = i(b'),  but 

Cfct(a)  “ cMUa'))  = i (C£a.*  (a * ) ) = i(d')  and  Cl&( f)  = 
C£6(i(b'))  = i(C£6'(b'))  = i(d)  thus  a f implies 
C£a(f)  ± CZstX aK 

A1.4  For  all  a e A»  m e M a = i (a ' ) and  m = i (c' ),  but 
Ci'i(a)  ~ 1 (d * ) and  C-taOn)  = i(d')  as  for  A1.3,  thus 
a m implies  C£a(m)  = ClA.(a). 

A1 .5  Similar  to  Al .3. 

A1 .6  Similar  to  Al .4. 

Al  .7  For  all  f e F>  f 88  l(b')  ar.d  b'  b'  In  S-j  thus  i(b')  <5 
i (b 1 ) and  so  f { f. 

A1.8  For  all  f,  g e F,  f = g = i(b')  thus  f 6 g and  g 6 f 
implies  f = g. 

Al . 9 For  all  f,  g,  h e F>  f = g = h = i (b ' ) and  since  b'  6 b'  in 
S-j 1 , i(b')  6 i(b'),  thus  f 6 g and  g 6 h implies  f 6 h. 

A1.10  For  all  f,  g,  h e F»  f=g=  h=  i(b'),  thus  g 6 f and  h 6 f 
implies  g 6 h or  h 6 f. 

Al .11  For  all  a e a and  f,  g e F>  and  f = g = l(b')  thus  a P g 
and  f 6 g implies  a Pfr  f. 

A1.12  For  all  a c A and  f,  g e F»  f = g = i(b')  thus  the  hypothesis 
in  the  implication  a g and  f 6 g and  f = g implies  a f 
can  not  hold  true  in  S- ' . Therefore  the  implication  holds  no 
matter  whether  a p^  f or  not. 
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For  all  a e A f,  q e f,  f = g = i(b')  thus  a ap  f and  f 6 g 
implies  a op  g. 

A1.14  For  all  f e F,  f = i(b')  and  a'  o'  b'  in  ' thus  there  exists 

a e A namely  a = i (a * ) such  that  a Op  f. 

Because  of  the  similarity  between  the  axioms  of  S g and  it  would 
be  simple  to  prove  the  counterpart  of  the  basic  theorem  of  Sg  directly 
in  S-j ; however,  we  prefer  to  prove  the  stronger  result  that  every 
theorem  of  Sg  is  a theorem  of  S.] . To  do  this  we  will  exhibit  a mapping 
from  the  formal  symbols  of  S-|  to  the  formal  symbols  of  Sg  which  preserves 
relationships.  Informally  we  might  view  this  as  showing  that  is  a 
valid  interpretation  of  Sg. 

Proposition  3.2:  There  exists  a one-to-one  correspondence  h from 

S.|  to  Sg  which  preserves  relationships. 

PROOF:  Since  the  sets  of  formal  symbols  may  be  assumed  to  be  equi- 

potent,  there  will  be  a one-to-one  correspondence  h from  the 
symbols  of  S^  to  the  symbols  of  SQ.  We  will  show  that  the 
relational  symbols  in  Sg  may  be  defined  so  that  h preserves 
the  relations.  First,  the  subsets  A,  R,  C,  in  S^  are  defined 

as  follows: 

Aq  = h(A.|),  R = h(FuM),  and  Cg  = h (C^ ) . (The  use  of  sub- 
scripts 0 and  1 to  indicate  elements  of  Sg  and  S-|  respective- 
ly should  be  clear.  This  convention  will  be  maintained  through- 
out the  following.) 

\ 

Second,  the  binary  relational  symbols  9,  y , ^ in  Sg  are  de- 
fined so  that  for  ag  e Ag,  rQ  e Rg,  cQ,  dQ  e CQ, 
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(3.2.1)  aQ  8 rQ  if  and  only  if  h"1 (aQ)  pp  h_1(r0)  or  h_1(a0)  PM  h~ 1 (rQ) , 

(3.2.2)  aQ  v rQ  if  and  only  if  h”1  (aQ)  a p h"1^)  or  h_1(aQ)  cM  h_1(r0), 

(3.2.3)  c0  £ dQ  If  and  only  if  h_1(c0)  ^ h_1(d0). 

(3.2.4)  And  finally,  = C^i(h"^ro^  and  C^1  ^ 1 (a) 

(Note  that  since  h is  a one-to-one  correspondence  it  has  an 
inverse  h”^  which  is  also  a one-to-one  correspondence.) 

Proposition  3.3.  Every  valid  interpretation  of  is  also  a valid 
interpretation  of  Sq. 

PROOF:  Let  the  relational  structure  S be  a valid  interpretation  of  S-j ; 

then  there  is  a one-to-one  correspondence  i-|  from  s to  a subset 
of  S-|  which  preserves  relations  and  such  that  the  axioms  of 
hold  true  in  S under  the  interpretation.  We  claim  that  the 
composite  function  ig  = IIq  o i^  (where  h is  the  function  produced 
in  Proposition  3.2  --  actually  the  restriction  of  h to  the  image 
of  S under  i-j  in  S-j ) from  S to  Sq  can  be  used  to  validly  inter- 
pret Sq  in  S.  i'q  is  a one-to-one  correspondence  since  it  is  the 
composition  of  two  one-to-one  correspondences.  Also  the  relation- 
ships in  S are  preserved  under  i^  and  h and  thus  under  iQ.  It 
remains  tc  be  shown  that  the  axioms  of  SQ  hold  true  in  S. 

It  will  be  useful  in  the  following  to  make  the  observation 
that  if  a = iQ(m)  = h(i^(m))  then  since  the  one-to-one  correspon- 
dence h has  an  inverse  h~^  it  is  true  that 

(3.3.1)  h-1 (a)  = i1 (m). 

A0.1  For  all  c c C there  exists  an  m e M such  that  ^(m)  = c. 

Since  axiom  Al.l  holds  true  in  S,  i-j(m)  ^ i-|(m);  thus,  since  h 
preserves  «,  h(i-|(m))  ^ h(i^(m)).  But  this  is  equivalent  to 
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AO. 2 


saying  iQ(m)  «g  iQ  (m)  or  c <q  c. 

' ■ ■ ■ 1 1 

For  all  c,  d,  e e Cg  there  exist  m,  n,  p e S such  that 
i Q (m ) = c,  i0(n)  = d,  and  iQ(p)  = e, 
c < g d implies  i-|(m)  «^i-|(n)  in  S-|  and  d «g  c implies 
i-|(n)  i i ( p ) in  S-j . Then  since  axiom  A1.2  holds  true  in 
S,  i i (m)  ^ i i ( p)  - Thus  h(i.|(m))  «g  h(i -j  (p) ) or  c «g  e. 

AO. 3 For  all  ag  e Aqj  r e R there  exist  m,  n e S such  that 

aQ  = ig(m)  and  r = i g(n) • thus,  if  aQ  9 r then  two  cases 
are  possible:(l)  i^(m)  Pj:  i -j  ( n ) and  (2)  i-|(m)  Pfr  i-|(n). 

Case  1.  By  axiom  A1.3,  ch>-\  (i-|  (n))  <jj  Cln.^  (i-|  (m)); 

thus  by  3.3.1,  (h"1  (r))  ^C-Ca-]  (h"1  (aQ)), 

and  by  3.2.4  CUQ(r)  «g  Ce/tgUg). 

Case  2.  By  axiom  A1.4,  CCa-j  (i -j  (n))  = ci&-\  (i -|  (m)) 
which  implies  C£a-|  (i -j  (n))  ^ cVi^  (i-|  (m)) 
and  the  rest  follows  as  in  Case  1. 

AO. 4 For  all  aQ  t Ag.  r E R there  exist  m,  ne  S such  that 

a0  = ig(m)  and  r = iQ(n);  thus,  if  a0  y r then  two  cases 
are  possible  (1)  i-j(m)  i-|(n)  and  (2)  i^(m)  i-|(n). 

Case  1.  By  axiom  A1.5,  Cfcrt-j  (i-|  (m))  ClSf  (i-|  (n) ) , 

thus  by  3.3.1,  CVi-\  (h~ 1 (aQ))  ^ CJU^  (h"1  (r)), 
and  by  3.2.4,  cin g (aQ)  <g  Cl&0(r). 

Case  2.  By  axiom  A1.6  C-Ca-j  (i-|  (m))  C£6i(i-|(n)) 

and  so  forth  as  in  Case  1. 

We  note  that  one  direct  result  of  Proposition  3.3  is  that  the  con 
sistency  of  implies  consistency  of  Sg,  Of  more  interest  is  the 
Corollary: 
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Corollary  2.4: 


Every  theorem  of  Sq  holds  true  in  every  valid 
interpretation  of  . 

PROOF:  By  Proposition  3.3  every  valid  interpretation  of 

will  also  be  a valid  interpretation  of  Sq  in  which 
every  theorem  holds  true. 

Specifically,  the  fundamental  theorem  T0.1  of  Sq  holds  true  in 
every  valid  interpretation.  Thus  we  can  say  that  in  any  valid  inter- 
pretation of  S-j  if  there  is  an  information  transfer  path  from  a given 
mailbox  or  file  to  a second  mailbox  or  file  then  the  security  class  of 
the  first  mailbox  or  file  is  less  than  or  equal  to  the  security  class 
of  the  second. 
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Appendix  C:  A Proof  of  Proposition  4.4.1 


To  show  that  every  S-|  c is  an  S-| , we  must  identify  all  elements 
in  S-j  in  terms  of  the  elements  of  S-|  ^ and  then  demonstrate  that  the 
S-j-axioms  are  satisfied  by  the  S i ^ structure  under  the  identification. 
This  will  show  that  every  ^ structure  is  a logically  valid  interpre- 
tation of  S-j . 

Given  S ^ ^ ^ ^ p ^ 

where  the  components  are  defined  as  In  lines  (4.4.1)  through  (4.4.10) 

In  terms  of  the  underlying  S2-structure,  let 

S'  = <F'  ,M' , A' , C’ , pp' , Op’ , p^|' , a^' , </  pSpCtb  ' ,cVi'>  where  the  sets  and  re- 
lations are  identified  below. 


pm’=  eS'  aM  ~ “S'  - = ^S> 

= cZis,  and  c&t'  = cJUs. 

We  will  then  show  that  this  S'  satisfies  the  axioms  of  S^ . In 

order  to  do  this  the  following  lemmas  will  be  needed: 

Lenina  C.l:  For  all  <e,s?,  <e,t>  e Es,  <e,s>  ir*<e,t>  implies 

cZns{<e> s>)  cZns  (<e,t>). 
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Proof: 


(By  induction)  Let  M = {n  £ N|<e,s>Trn<e,t>  implies 
clns(<e, s>)  « cZ^(<e,t>)  for  all  <e,s>,  <e,t>  e E$) 

First:  0 eM  since  <e,s>Tr°<e,t>  implies  <e,s>=<e,t>  and  we  have 

cln.^(<e,s>)  = ct^5(<e,t>). 

Second:  Suppose  n e M,  then  consider  n + 1.  If  <e,s>  and  <e,t> 

n+  ^ 

e and  <e,s>Tr  <e,t>^  then  there  exists  an 
<e,u>  e such  that  <e,s>Trn<e,u>  and  <e,u>ir<e,t>.  By. 
the  inductive  hypothesis  the  first  implies  c£/tg(<e» s>) 

± u>,  and  by  definition  the  second  implies  u x t. 

In  an  S^-secure  structure  x is  permissible.  Hence,  by 
axiom  A2.12,  cZn^ie)  ± cln^{e)',  therefore  by  (4.4.5) 
cIa$  <e,u>  <_  c£/tg(<e,t>).  The  transitivity  of  < (A2.16) 
gives  the  desired  cZn.^{<ey s>)  <_clA^{<e, t>).  Thus,  n+1 
£ M.  By  induction  M=N,  and  the  property  holds  for  all 
n £ 0.  Hence  the  implication  holds  for  it  = U <rn. 

The  proofs  of  the  next  two  lemmas  are  analagous  and  are  omitted. 

Lemma  C.2  For  all  <f,s>,  <f,t>  £ F^>  <f,s>  TT*<f,t>  implies 
c^s(<f,s>)  c£4^(<f >t>) . 

Lemma  C.3  For  all  <m,s>,  <m,t>  eM5>  <m,s>  TT*<f,t>  implies 

cEAs(<m,s>)  ± c£ss(<m,t>). 

We  now  turn  to  the  results  needed  to  show  S1  5 is  an  example  of  s1 . 

Axioms  Al.l  and  A1.2  are  immediate  consequences  of  axioms  A2.15  and  A2.16. 

A1.3:  For  all  <e,s>  e E$,  <f,t>  e Fs>  <e,s>  <f,t>  implies 

cts«(<f,t>)  < cl*s  (<e,s>) . 
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Proof: 


By  (4.4.7), <e,s>  x>  <f,t>  implies  there  exists  u e s 
such  that  e e f e Fu»  e ^ f,  <f  ,t>ir*<f  ,u>  and 
<e,u>u*<e,s>.  By  $2-security  the  state  u is  reachable 
from  some  secure  state  through  permissible  and  (hence 
preserving)  transitions;  thus,  u is  statically  secure, 
and  e vu  f implies  cZ&u(f)  « cZn^(^)  or  equivalently 
c^s(<f,u>)  ^c£^s(<e»u>).  Also  by  lemma  C.l  we  have 
c£^(<e,u>)  _<  cJbiA<e*t>)  and  by  lemma  C.2  we  have 
cf^^(<'ir,t>)  < ££*  (<f,u>).  Those  results  and  axiom 

A7.16  (transitivity)  gives  ^ (<f,t>)  < ^ (<e,s>). 

5 5 | | 

The  analogous  proofs  of  the  next  three  lemmas  are  mercifully 
omitted. 


A1.4: 

A1.5: 

A1.6: 

A1.7: 

Proof: 


A1.8: 


Proof: 


For  all  <e,s>  e <m>t>  e M^,  <e,s>  <m,t>  implies 

c^A5(<m,t>)  = d£/ig(<e,s>). 

For  all  <e,s>  e E^,  <f,t>  e F^,  <e,s>  <f,t>  implies 

(<e,s>)  4cJU>A< f,t>). 

For  all  <e,s>  e E<. , <m,t>  eM^,  <e,s>  <m,t>  implies 

(<e,s>)^  (<m,t>). 

For  all  <f,s>  e F^,  <f,s>  <f,s> 

By  (4.4.2)  f e Fs,  and  since  every  state  in  S2  is 
statically  secure,  axiom  A2.5  holds  and  implies  f f. 
Hence,  by  (4.4.4)  we  get  <f,s>  6 ^ <f,s>. 

For  all  <f,s>,  <g,t>,  e F^ , <f,s>  6^  <g,t>  and  <g,t> 

6^  <f,s>  implies  <f,s>  = <g,t>. 

By  (4.4.2)  f eF$  and  g e Ft,  and  by  (4.4.4)  s=t, 
f <Ss  g,  and  g f.  But  in  the  statically  secure  state. 
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axiom  A2,6  implies  that  f=g;  hence, <f,s>  = <g,t>. 

A1.9  For  all  <f,s>,  <g,t>,  <h,u>  e <f,s>  6^  <g»t>  and 

<g,t>  6^  <h,u>  implies  <f,s>  6^  <h,u>. 

Proof:  Briefly,  (4,4,4}*  implies  s=t=u,  f <$  g,  and  g <5  h, 

l» 

and  axiom  A2.7  implies  f h which  by  (4,4,4)  yields 

<f,s>  6^  <h,u>.  BH 

A1.10  For  all<f,s>,  <g,t>,  <h,u>  £ <f,s>  <5^  <gst>  and 

<h,u>  6^  <g,t>  implies  <f,s>  <5^  <h,u>  or  <h,u>  <5^  <f,s>. 

Proof:  By  (4.4.4)  s=t=u,  f 6S  g,  and  h <5S  g,  and  in  the  stati- 

cally secure  state  this  means  by  axiom  A2.8, f h or 

h 6s  f.  Thus,  «f,s>  6^  <h,u>  or  <h,Uf>-  <$5  <f,sf, 

Al.ll  For  all  <e,s>  e Es>  <f»t>,  <g,u>  e fs  <e,s>  <9»u> 

and  <f,t>  6^  <g,u>  implies  <e,s>  <f,t>. 

Proof:  (4.4.4)  and  <f,t>  $s  <g,u>  implies  t=u  and  f <$t  g. 

<e,s>  <g,t>  implies  by  (4.4.7)  there  is  a v e s such 

that  e e Ev,  g e Fv,  e vv  g, 

<e,v>Tr*<e,s>  and  <g,t>iT*<g,v>.  By  A2.7  g e Fy 
and  f <5 1 g implies  f e Fv  and  f 6V  g.  Then  since  state 
v is  statically  secure  we  have  A2.9  e f.  Thus  v 
is  a state  in  which  e e F , f e Fy,  e vy  f and  <e,v>n* 
<e,s>.  If  we  can  show  that  <f,t>ir*<f ,v>,  we  will  have  the 
desired  result  <e,s>  <f,t>.  By  axiom  A2.17,  f exists 

in  every  state  which  contains  g.  If  <g,x>iT<g,y>  for  states 
x,  y e S,  it  must  be  true  that  f e F and  x t y;  thus, 
<f,x>  it  <f,y>.  By  induction  this  extends  to  tt*;  therefore, 
<g,t>  it  <g,v>,  and  f 6t  g implies  <f,t>  it*  <f,v>. 


The  same  technique  gives: 


A1.12  For  all  <e,s>  e E^,  <f,t>,  <g,u>  e Fs,  <e,s>  as  <g,u>, 

<f,t>  6^  <g,u>,  and  <f,t>  f <g,u>  implies  <e,s>  vs  <f,t>. 

And  finally  we  have: 

A1.13  For  all  <f,s>,  <g,t>  e F^,  <f,s>  6^  <g,t>  implies 
f,s>)  _<  cZii(<g,t>). 

Proof:  By  (4.4.4)  <f,s>  6^  <g,t>  implies  s=t  and  f g.  Also, 

an  S^-secure  structure  state  s is  statically  secure;  thus, 
a&s( f)  <_  cZA$(g)  which  by  (4.4.6)  gives  ,s>)  £ 

c£ s5(<g,s>). 
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Appendix  D:  Proofs  Concerning  the  Sg  Events 

We  must  show  that  the  events  presented  in  chapter  5 have  suffi- 
cient conditions  and  properties  to  guarantee  that  security  is  not 

compromised.  We  will  demonstrate  that  the  axioms  presented  in  sec- 
tions 4.2-4  are  satisfied.  In  ether  words,  based  on  the  assumption 
that  the  computation  is  in  a secure  state  before  the  event,  we  will 
prove  that  the  event  occurs  in  accordance  with  the  transition  axioms 
(A2.12  - A2.17  ) and  that  the  new  state  is  locally  secure  (axioms 
A2.1  - A2.ll). 

Thus  there  are  seventeen  axioms  to  be  proved  for  each  of  the 
seventeen  events.  Fortunately,  however,  it  has  oeen  found  that  often, 
a given  event  has  no  effect  on  several  of  the  axioms.  For  example 
the  "Connect  file"  event  in  no  way  affects  the  mailboxes  or  the  axioms 
concerned  with  them.  In  addition,  a proof  for  some  axiom  from  event 
x may  be  identical  or  extremely  close  to  the  arguments  used  for  prov- 
ing the  same  axiom  from  event  y.  We  have  therefore  chosen  to  prove 
that  each  axiom  holds  for  all  events  rather  than  prove  that  each  event 
satisfies  all  axioms.  In  effect,  there  is  a two  dimensional  array  of 
proofs  to  be  made  (see  figure  D.l  ) and  we  have  chosen  to  traverse 
rows  first. 


evl 

axiom  2.1 

ev2 

ev3 

• • • 

evl  7 

axiom  2.2 

• 

axiom  2.17 



Figure  D.l 
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Axiom  A2J  For  all  e-,  £ E,  f-|  e F,  e-|  v f-j  CLS  (f^ ) < CLR(e-|). 

We  shall  assume  that  the  system  is  in  some  secure  state.  As  a 
result,  we  can  assume  that  axiom  A2.1  is  true  before  the  event  occurs. 

We  must  now  show  that  after  the  occurence  of  any  event,  we  have: 
e-j  v'  f.|  CLS' (f-| ) _<  CLR1  (e-| ). 

Case  1 El  (e  becomes  view-connected  to  f).  By  PI. 6 - 

e-j  v1  f-j  only  if  e-j  v f-j  OR  e-|  = £ and  f-j  = £ and 
the  conditions  are  met. 
i)  e-|  v f ^ 

CLR'  (e-| ) = CLR^)  and  CLS'  ) = CLS^)  by  PI. 2 
and  PI. 11.  Using  the  assumption,  CLS'(f-|)  = 

CLS(f  1 ) « CLR(e-| ) = CLR*  (e-, ) . 


ii) 

el  = A fi  = £ a Cl . 1 a Cl.  2 a 

CLS1  (f-j ) < CLR'  (e-j ) due  to  Cl. 2. 

Case  2 

E3 

e is  disconnected  from  f. 

If  e-|  v'  f1  then  e-j  v f-| . But  CLS'(f-|)  = CLS(f-|)  and 
CLR  '(e-j)  = CLR(e-|)  by  P3.2  and  P3.ll.  However,  we 
obtain  CLS*  (f  1 ) = CLS(f ^ ^CLR(e1)  = CLR'^),  using 
the  assumption. 

Case  3 E5  (destroy  file  f).  By  P5.6 

We  have  e-|  v'  f-j  only  if  e-j  v f-j  and  (f  6 f-j 
a C5.1  a C5.2) . But  this  information  means  that 
CLS 1 (f -j ) = CLS( f-|)  and  CLR'Ce^  = CLR(e-|)  by  P5.2 
and  P5.ll  respectively.  Using  the  assumption  as 
in  the  previous  case,  CLS'(f-|)  ^CLR'(e-j). 

Case  4 E7.  (raise  classification  of  f to  £)  By  P7.6 

We  have  e-j  v'  f1  only  if  e-jV  f-j  and  [ 1 (f -]  = £ 

a C7.1  a C7.2  a C7.3)  OR  C < CLR(e-, )]  due  to  P7.6. 
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Case  5 

Axiom  A2.2 

We  must 
Case  1 


Case  2 


i)  ,(f1  = f a C7.1  a C7.2  a C7.3). 

In  this  case  CLS'  (f-j)  = CLS(f-|)  and  arguments 
for  Case  2 apply. 

ii)  C C LR ( e i ),  conditions  are  satisfied. 

CLS'(f-|)  = C from  P7.2  . Thus  CLS' ( f-j)  = 

C < CLR(e-| ) = CLR1  (e-j ) . 

All  other  events. 

Px.2  and  Px.ll  guarantee  CLS'  (f  i ) = CLS(f-|)  and 
CLR'(e-j)  = CLR(e-j).  See  Case  1 i for  proof. 

For  all  e-j  e E,  m]  e M,  e-,  a m1  =*p  CLR(e-,)  = M-CLS(m.,). 

show  e^  a'  m-|  CLR' (e-( ) = M-C/-S * (m-j ) . 

E9  becomes  receive- connected  to  f).  By  P9.9: 
e-j  g'  m only  if  e-j  a m-j  OR  (e-j  a e,  a m-j  = m a C9.1). 
i ) e-|  a m, . 

But  from  the  assumption  CLR(e-j)  = M-CLS(m-|). 

Using  P9.7  and  P9.ll  we  find  that  M-CLS  and 

CLR  are  unchanged.  Hence:  M-CLS'  (m^)  = M-CLS(m-|)  = 
CLR(e-j)  = CLR'(e-j). 

ii ) e-|  = e a = m a C9.1 . 

From  C9.1  we  know  CLR(e^)  = M-CLS(m).  Using  the 
arguments  in  part  i),  M-CLS'  (m-j ) = CLR(e-, ) . 

Ell  (e  becomes  disconnected  from  mailbox  m). 

From  e-j  g'  m-j  we  know  e-|  g m-|  by  using  P11.9.  In  a 
manner  similar  to  the  previous  case  we  show  M-CLS ' (m-j ) 

= M-CLS(m-| ) = CLR(e-j ) = CLR'(e 1). 
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By  P12.9: 


Case  3 
Case  4 
Case  5 

Axiom  A2.3 

We  must 
Case  1 


Case  2 


El 2 (raise  classification  of  m to  £) 

e-j  3*  m-j  only  if 1 (m-j  = m a C12.1  a C12.2) 

From  PI 2. 7 we  find  M-CLS'(m-|)  = M-CLS(m-|).  The  argument 
proceeds  as  in  case  1. 

E16  (e  raises  its  own  clearance  to  C). 

e-j  3'  m-|  only  if | (e-|  = £a  C16.1)  due  to  P16.9. 

But  this  means  CLR‘  (e-, ) = CLR(e-|)  due  to  P16.ll.  As 
in  previous  cases  M-CLS’'(mi)  = CLR(e-|). 

All  other  events. 

By  Px.7  and  Px.ll  M-CLS'  (m1 ) = M-CLS(m-| ) and  CLR'(e-,)  = 
CLR(e-|).  See  case  1 i. 

For  all  e-j  e E,  f-j  e F,  e-|  a f-|  ^CLR(e-|)  <*CLS(f-|). 

show  e-,  a'  fi  CLR'Ce-,)  < CLS'(f-,). 

E2  (e  becomes  alter-connected  to  f).  By  P2.5: 

e-j  f-|  only  if  e-|  a f-|  OR  (ep  e A f j = f a C2.1 
a C2.2  A C2.3) . 

1 J ei  a f i 

From  P2.2  and  P2.ll  we  get  CLS'(f-|)  = CLS(f-|) 
and  CLR'(e-|)  = CtR(e-|).  Using  the  assumption 
we  obtain:  CLR'(e-,)  - CLR(e-|)  ± CLS{ f,)  = CLS'  (f-j ) . 

ii)  e,  ■ e a f i B f a C2.1  a C2.2  a C2.3. 

From  C2.2  we  get  CLR(e-| ) < CLS(f-j).  The  rest  of 
the  argument  follows  i). 

E3  (e  becomes  disconnected  from  £). 

If  e-j  ct1  f.|  then  e-j  a f-j  due  to  P3.5.  But  as  in  pre- 
vious cases,  classifications  and  clearances  don't 
change.  Therefore  CLR'  (e-| ) « CIS' (f-j). 
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Case  3 E5  (destroy  file  _f). 

If  e-,  o'  f1  then 1 (f  6 f]  a C5.1  a C5.2)  by  P5.5. 

But  this  neans  CLR'(e^)  = CLR(e-|)  and  CLS'(f-|)  = 
CLS(f-j).  By  th<.  same  reasoning  as  previous  cases, 

CLR'  (e-| ) ± CIS'  (f-,). 

Case  4 El 6 (ej  raises  its  own  clearance  to  CJ 

From  PI 6. 5 we  know  e-j  a'  f-|  only  if  e-|  a f-|  and 
[C  ± CLS(f-| ) OR  ^ (C16.1  a ei  = e)] 

i)  1 C16. 1 OR 1 e]  = e 

In  this  instance  the  clearance  doesn't  change 
and  previous  arguments  apply. 

11)  C±CLS{f]) 

By  PI 6. 11  CLR'(e^)=C  for  e-|  = e^.  By  transitivity, 
CLR'(e<|)  = C<_CLS(f-|),  but  P16.2  guarantees  that 
CLS1  (f -j ) = CLS(f-| ) 

Case  5 All  other  eve  ts. 

From  Px.2  and  Px.ll  we  know  CLS' (f-| ) = CLS(f-|)  and 
CLR'(e^)  = CLR(e-|).  Arguments  follow  Case  1 i. 


Axiom  A2.4  For  all  e-j  € E,  m-j  e M,  e-|  u m-j  CLR(e-| ) 4M-CLS(m-|). 

We  need  to  show  that  e-|  u>'  m-j  ---  ^ CLR'  (e-^ ) 4 W-CLS1  (m, ) , however, 
since  the  proofs  are  similar  to  those  in  axiom  A2.3,  they  are  omitted. 


154 


Axiom  A2.5 


Case  1 
In 

implies 
Case  2 


Case  3 


For  all  f-|  in  F,  f-|  6 f-| . 

We  must  show  that; 

For  all  f-|  in  F' , f-|  61  f-| 

All  events  except  E4  (create  file  f_  in  dj  and  E5 
(destroy  file  f in  dj 
each  of  these  events  we  have,  due  to  property  X.4,  f-|  <5  f£ 
f-|  6'  f 2 . Substituting  f-|  for  Qives:  f-|  s'  f -j . 

E4  (create  file  in  d_) 

Clearly  by  P4.4,  if  f-j  6 f then  f-|  s'  f -| . The  other 
possibility  is  that  f-|  = f - the  newly  created  file. 
But  also  f-|  = ^2  = L implies  f-|  s'  f2  which  in  turn 
implies  by  substitution  f-|  s'  f -| . Hence  for  all 
f 1 e F ' » f i 6 1 f i • 

E5  (destroy  file  f_  in  dj 

By  definition,  only  those  files  which  exist  after  the 
event  are  members  of  F 1 . Thus  "ST ' (f-| ) = USED"  is 
equivalent  to  f,  e F1.  Using  this,  property  P5.1 
(contrapositive)  yields  -if  s f-i  (assuming  that  the 
conditions  are  satisfied). 

If  some  condition  is  not  satisfied  then  by  P5.4 
f 1 6 1 ^2  if  and  only  if  f-,  <$  By  substitution, 

f-j  6'  fi  iff  f -j  6 f -j  • 
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Continuing,  from 

Axiom  2.6 
Show  that: 

Case  1 


P5.4  we  also  get:  if  f-j  6 f and — if  6 f-j  then  f-|  61  f -j . 
Thus  we  have  for  all  f-j  e F',  if  f ] 6 f-|  then  f-|  61  f -| . 

For  all  f -j , f2  e f-|  <5  f2  A 5 ^1  =t^  ^1  = ^2' 
for  all  f -j , f2  e F1  f-|  6'  f2  a f2  6*  f-j  f-|  = f2. 

E4  (create  file  f_  in  d_) 

By  property  P4.4  if  f-|  6'  f2  then  either  f-|  6 f2  OR 
(f1  6 d and  f2  = f)  OR  f]  = f2  - f.  Similarly  f 2 6 ' f-, 
implies  f2  6 f-|  OR  (f2  6 c[  and  f-|  = fj  OR  f2  = f-|  = f. 

i)  Clearly  if  f-j  $ f2  and  f2  s f<j  then  f-|  = f2  by  the 
assumption.  Furthermore,  by  definition,  ST(f^)  = 

ST(f2)  = USED.  Since  by  C4.4  ST(f)  = UNUSED  we  know 
that  fi  f f a f f for  this  subcase. 

11)  "F-i  = f2  = "f  satisfied  trivially 
iii)  Finally  we  can  show  that  the  last  subcase 

f-|  6 d a d 6'  f2  and  f2  = f implies j (f 2 61  f -| ) 

For  a proof  by  contradiction,  suppose  f2  61  f -| . 

Then  since  d 6 f2  we  find  by  transitivity  d 6'  f-j. 
Now  f-j  6 d implies  f-j  6'  d by  P4.4.  Using  this 
fact  with  d 6'  f2  we  get  f-|  6'  f2.  However  by 
C4.3  we  have — i(d  6'  f-j  a 6'  f)  0r  substitu- 
ting   i(d  6 1 f-|  a 6 1 f ) - a contradiction. 

Thus  if  f-j  6'  f2  and  f2  6'  f-j  then  either  f-|  = f2  = f. 

OR  f-j  6 f2  and  f2  <5  and  f-j  = f2. 
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Case  2 

All  other  events. 

If  f-|  <5'  f2  then  f-|  6 f2  because  of  property  PX.4. 
Similarly  f2  6'  f-j  implies  that  f2  6 f -| . But  f2  6 f-| 
and  f-|  6 f2  yield  the  result  f-|  = f2  by  the  assumption 

A2.7 

f 1 » f 2 > fg  e P > f *|  5 f 2 A ^ ^ ^ f i fi  fg 

Show  that 

fp  f2,  f3  € F\  ^ 6 1 f2,  f2  6'  f3=^f1  f3. 

Case  1 

E4  (create  file  _f  in  d) 

i)  fi  > f2,  f3  € F - By  the  assumption,  f-|  6 f2> 
a f2  6 f3=^f-|  6 fy  Thus  f^  6 1 f3  by  P4.4. 

11)  fp  f2  e F,  f3  = f,  f e F'; — i(f  c F).  By  P4.4, 
f2  6 1 f3  only  if  f 2 6 d . By  transitivity  f-|  6 d. 
But  f-|  6 d means  that  f-|  6'  f3  also  due  to  P4.4 
(assuming  all  conditions  are  met). 

Lemma  1 

If  f->  = f a f-j  6 f 2 then  f-j  = f2  = f.  By  P4.4b 
f 6 f2  implies  f = f2- 
iii)  f1  e F,  f2  = f. 

Clearly  if  f2  = f and  f2  6 f3,  then  by  lemma  1 
we  must  have  f2  = f3  = _f . Thus  f-|  6'  f3  since 
f1  6 1 f2. 
iv)  f 1 = f 

By  lemma  1 > f-j  = f 2 = f3  = £•  By  axiom  A2.5 
fl  «■  f3' 

Case  2 

all  other  events. 

From  f-j  6 1 f2  and  f 2 6 1 f3  we  obtain  f-|  6 f2 
and  f2  6 f3  from  properties  Px.4.  Furthermore,  the 
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Axiom  A2.8 

We  must  show 
Case  1 


Case  2 


Case  3 


transitivity  assumption  assures  that  f-j  6 fg.  But 
using  Px.4  again  we  get  f,  6'  fg. 

For  f i , f2,  e F,  f-j  6 fg  and  f2  <5  fg  f2  6 f-j 
OR  f-  6 f2. 

6 ' fg  A f2  6'  fg  =4  f1  6 ' f2  OR  f2  6'  fy 
E4  (create  file) 

i)  f-j,  f2>  fg  e F is  true  by  the  assumption, 

ii)  Given,  f -j , f2  e F,  fg  = f and  all  conditions  are 

met  then  f-j  6'  fg  implies  f-j  <S  d by  P4.4.  Simi- 
larly, if  f2  6 1 fg  then  f2  6 d.  But  combining 
these,  we  get  f-j  6 f2  or  f2  6 f-  by  the  assumption. 
From  P4.4  we  know  f-j  f2  or  f2  6'  f-j 
iii)  f2  * f 

Using  Lemma  1,  we  know  also  that  fg  = f.  Since 

f-j  6 1 fg,  we  must  also  have  f-j  6'  f2. 

Similar  arguments  apply  if  f-j  = f_  or  both  f-j  and 
f2  are  equal  to  f. 

E5  destroy  file  f_  in  d.  From  f-|  <5'  fg  and  f2  <s'  fg 

we  know  f-j  6 fg,  f2  6 fg, i(C5.1  a C5.2  a f $ f ) 

and |(C5.1  a C5.2  a f <$  f^)  due  to  P5.4.  From  the 

assumption  we  know  either  f-|  6 f2  OR  f 2 6 f -| . Knowing 

this  along  with |(C5.1  a C5.2  a f <$  f^)and  (C5.1 

a C5.2  a f 6 f2)  gives  us  f-j  6'  f2  OR  f2  6'  f-j  using  P5.4. 
All  other  events. 

From  f-j  6 1 fg  and  f2  6‘  fg  we  know  f.]  6 fg  and  f2  6 fg 
by  Px.4.  From  the  assumption  we  know  either  f-j  6 f2 
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Axiom  A2.9 

We  must 
Case  1 


Case  2 


OR  f2  6 f1 


f2  «■  fr 


Now  using  Px.4  we  obtain  f-|  6'  f2  OR 


For  e-|  c E,  f2  e F,  e-|  v f2,  f-j  6 f2  implies 
e,  v fr 

show  e-j  v1  f2,  f-|  6 1 f2  implies  e-|  v*  f -| . 

E-|  e^  is  view-connected  to  f. 

From  PI. 6 we  get  two  possibilities. 

i)  e-j  v'  f2,  Ke-|  v f2) 

From  Cl. 3 we  know  e v d,  e can- view  _f's  parent. 

And  by  the  assumption,  f-|  6 d implies  e v f^. 

We  must  show  that  if  f-|  <5'  f then  f-|  6 d.  When 

f was  created,  condition  C4.3  guaranteed 

|(d  6 f-|  A f-j  6' f)  for  any  f -j . Hence  f-j  6'  f 

a d 6'  f means  that  f-|  <S  d because  of  C4.3  and 

Axiom  A2.8.  Thus  for  all  f2  = f and  e-|  = e, 

f-j  <5  f0  and  e v f 2 imply  e-|  v f^  and  hence  e-j  v'  f*|* 

ii)  e1  v f 1 (Cl.l  a ci.2  a ci.3  a e-,  = e a f]  = f) 

For  all  e1  e E,  f1  e F,  e-|  v'  f^  only  if  e-|  v f» 

due  to  PI. 6.  But  if  e^  v f^  and  f-|  <S  f2  then 

e-j  v by  the  assumption  and  hence  e-|  v'  f-| 

E3  (disconnect  file  f) 

From  P3.6,  we  know  that  e-|  v'  f^  only  if  e-|  v f2  and 

i(e-|  = e a f 6 f2  a C3.1).  But  since  f-|  <S  f2, 

if r(f  6 f2)  then |(f  6 f^).  Hence |(e-|  = e 

a f 6 f-|  a C3.1)  must  also  be  true.  This  along  with 
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Case  3. 


Case  4. 


the  assumption  that  e-j  v f-j  means  e-j  v1  f-j  by  P3.6. 

E5  (destroy  file  f) 

Using  P5.6,  e-j  v'  f2  assures  e-j  v f2  and  1 (f  6 f2 

a C5.1  a C5.2).  Using  reasoning  similar  to  that  in 

Case  2,  we  know  , (f  6 f-j  a C5.1  a C5.2)  is  also 

true.  Also,  e-j  v f2  only  if  e^  v f-|  because  of  the 
assumption.  But  now,  e-|  v'  f-j  also  due  to  P5.6. 

E7  (raise  classification  of  JF) 

i)  i(f  6 f2)  (neither  file  is  in  f's  subtree) 

— r(f  6 f2)  only  if  f f f2-  But  this  and  e-  v f2 

means  e-j  v'  f2  due  to  P7.6.  Since  f-j  6 f2,  we 

know  e-|  v f-j  from  the  assumption.  Furthermore, 
we  can  show  e-j  v'  f-j  by  similar  reasoning.  Since 
f-j  6'  f2  only  if  f-|  6 f2,  we  have  shown  that 

f-|  6'  f2  and  e-j  v'  f2  implies  e-j  v'  f-j  where  f-j 

and  f2  are  not  in  f's  subtree. 

11)  f 6 f2  (at  least  one  of  the  files  is  in  _f's  subtree.) 

From  e-j  v'  f-j,  P7.6  guarantees i(f  = f-i  A 

C7.1  a C7.2  a C7.3)  0RC£CLR(e1) 

We  know  from  P7.2  that  CLS'^)  = 

CLS(f2).  But  by  the  data  acquisition  axiom  (A2.1) 
CLS'(f2)  ± CLR(e-j).  And  by  axiom  A2.ll  CLS(f-j) 
^CLS(f2).  Furthermore,  C7.3  guarantees  that 
CLS1  (f-j)  CLS(f2)  if  f-j  happens  to  be  f. 

Therefore  for  any  f-j  such  that  f-j  6 f2,  CLS'(f-j) 

± CLS(f2)  £CLR(e-j).  But  this  is  sufficient  (using 
property  P7.6)  to  show  e-j  v'  f, . 
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Case  5 


All  other  events. 


Axiom  A2.10 

We  must 
Case  1 E2 


Case  2 


Properties  Px.2  and  Px.ll  guarantee  CLS'(f-|)  = 

CLS(f1),  CLS'(f2)=CLS(f2)  and  CLR'  (e^  = CLR(e^). 

See  case  1 ii  for  proofs. 

For  all  e-j  e E,  f -j , f 2 e F,  e a f2,  f-j  6 f2  and  f-|  f f2 


show  that  e-|  a1  f2,  f-j  61  f2  and  f-j  f f2  =4  e-j  v1  f -| . 

(e  is  alter  connected  to  f) 

From  property  P2.5,  we  know  that  e-j  a f2  OR  (e-|  = e^  a 
f2  = f a C2.1  a C2.2  a C2.3)  if  e}  «•  fg. 

i)  e-|  af2 

By  the  assumption,  for  all  f-j  6 f2>  e-|  v f -| . 

But  we  know  e-j  v'  f-j  also. 

ii ) e-j  = e.  A = f_  a C2.1  a C2.2  a C2.3.  From  C2.3 
we  know  e v d,  (We  defined  d:  d 6 f2  and 

V f-j  6 1 f2,  f-|  6 d,  that  is  all  files  which  do- 
minate f2  also  dominate  d.  ) But  using  axiom  A2.9 
we  prove  e-j  v f-j  given  e-|  v d.  But  if  e-|  v f-| 
then  e-j  v'  f -j . 

E3  (disconnect  e_  from  file  fj. 

From  P3  5,  e-j  a1  f2  implies  e-j  a f2  and |(e-|  = e a 

f 6 f2  a C3.1).  Now  e-j  a f 2 and  f-j  6 f2  and  f-j  f f2 
means  e-|  v f-j  because  of  the  assumption.  But  since 

1 (e-|  = e a f <s  f^  a C3. 1 ) and  f-|  6 f2  only  if 

l(e-|  = e A f 6 f-j  A C3.1 ) , we  know  e-|  v'  f-j  due 

to  property  P3.6. 
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Case  3 


Case  4 


Case  5 


Case  6 


E5  (destroy  file  f_)  By  P5.5 

e-|  ex'  implies  e-|  a f2  and |(f  6 f-|  a C5.1  a C5.2). 

Using  arguments  similar  to  those  in  case  2,  we  find 
e-|  v f.  and  furthermore  e-j  v1  f-|  using  P5.5  and  P5.6. 

E7  (raise  classification  of  £). 

From  P7.5  we  know  that  e-|  a f2  and  [ i(f  6 f2  A 

f = f2  a C7.2  a C7.3)  OR  C £ CLR(e-,)].  The  arguments 
closely  follow  those  for  axiom  A2.9  and  shall  only  be 
summarized:  If  neither  file  is  in  £ 's  subtree,  the 

view  relation  remains  the  same.  In  fact  as  long  as 
f-j  is  not  in  the  subtree  "e-|  can-view  f-|"  is  unchanged. 
If  f-j  is  in  the  subtree  (but  it  is  not  f)  the  change 
in  classification  can  not  exceed  f-|'s  classification 
so  e-j  still  can-view  f -| . If  f-|  = f,  then  P7.5  guaran- 
tees that  f-j  remains  at  a compatible  classification. 

El 6 (e  raises  its  own  clearance) 

e-j  a1  ^ lmP^es  ei  a f2  and  hence  for  f-|  6 f2,  e-|  v f ^ . 
But  the  "can-view"  relation  is  unchanged  hence  e-|  v'  f -| . 
All  other  events. 

Properties  Px.2  and  Px.ll  guarantee  CLS1  (f-| ) = CLS(f-|), 
CLS'(f2)  = CLS(f2)  and  CLR'  (e-|)  = CLR(e-|).  See  case 
1 i for  proof. 
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Axiom  A2.ll 

We  must 
Case  1 


Case  2 


Case  3 


fp  f2  e F,  f-|  6 f2  CLS(f-j)  « CLS(f2). 

show  f1  6'  f2  CLS  ' (f-| ) ^ CLS'  (f2) . 

E4  (create  file  £ in  dj. 

From  P4.4,  -f-j  6 -f2  OR  (f-j  6 d A f2  = f A C4.1 
a ...  a C4.6)  OR  (f-|  = f2  = f.  A C4.1  a ...  C4.6). 

i )  f-j  6 f 2 

CLS*  (f-, ) = CLS(f})  * CLS(  f2)  = CLS'(f2). 

ii)  f-|  s d a f2  = f a C4.1  a ...  a C4.6.  From  C4.3 

1 (f-j  6 1 f2  Ad  6 f-j).  But  this  means  f-|  6 d 

due  to  axiom  A2.4.  We  know  CLS(f-j)  < CLS(d)  and 
from  P4.2,  CLS'  (d)  = CLS(d)  and  CLS'(f-|)  = CLS(fj). 
Furthermore  C4.5  and  P4.2  guarantee  that  CLS(d) 

± CLS ' (f2).  Hence  CLS 1 (f i ) 5 CLS'(f2). 

iii)  f 1 = f2  = f 

CLS' (f-j)  = CLS ' (f 2 ) and  hence  CLS'(f-j)  < CLS'  (f2) 
trivially. 

E5  (destroy  file  f_). 

For  all  files  f2  in  use  (ST(f2)  t UNUSED), T(f  6 f2 

a C5.1  a C5.2) . But  also, |(f  <5  f]  a C5.1  a C5.2). 

Hence  CLS' (f7 ) = CLS(f])  and  CLS'(f2)  = CIS(f2)  by  P5.2. 
Thus  CLS' (f^ ) = CLS(f})  < CLS( fg)  = CLS'(f2). 

E7  (raise  classification  of  £). 
i)  f-|  = f and  conditions  are  met. 

CLS'(f)  = C due  to  P7.2.  But  for  all  f2  such  that 
f-j  6 f2  C CLS(f2)  due  to  C7.3.  Thus  CLS' (f-j)  < 
CLS'{ f2). 
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Case  4 


ii)  t2  = f and  conditions  are  met.CLS1  (f-| ) = CLS(f-|) 

and  CLS'(f2)  = C due  to  P7.2.  From  the  assumption, 
CLS( f i ) < CLS(f2).  From  C7.3  and  P7.2  we  know 
CLS(f2)  < CLS'( f2)  = C.  Thus  CLS'  (f-j ) < CLS'(f2). 

ill)  Conditions  are  not  met.  By  P7.2  CLS'(f-|)  - CLS( f ) 


and  CLS'(f2)  = CLS(f2).  Using  the  assumption  we 
can  show  CLS'^)  CLS'(f2). 

All  other  events. 

Px.2  guarantees  CLS'(f-,)  = CJLS(f-,)  and  CLS ' (f 2)  = CLS(f2). 
See  case  1 i for  proof. 
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Axiom  A2.12 
Case  1 


Case  2 


For  all  e-j  e E,  CLR(e- ()  <CLR'(e-|). 

El 6 e^  raises  its  clearance  to  £. 

Property  PI 6. 11  guarantees  that  either  CLR'(e-|)  = 
CLR(e-|)  and  the  axiom  is  satisfied  trivially  or 
CLR'(e-|)  = C.  But  C16.1  assures  us  that  CLR(e-|)  < C. 
All  other  events. 

From  property  Px.ll  we  know  CJLR'(e-|)  = CLR (e-j ) and 
thus  the  axiom  is  satisfied  trivially. 


Axiom  A2.13 
Case  1 


Case  2 


Case  3 


For  all  f-|  c F,  CLS(f-|)  <CLS'( f-|). 

E4  (create  £ in  dj. 

i)  id.6  f-|  a C4.1  a ...  a C4.6) . 

From  P4.2  we  find  CLS'(f-|)  = CLS(f-|)  and  thus 
the  axiom  is  satisfied  trivially, 
ii)  f 5 f|  a C4.1  a ...  a C4.6.  (f  = f.j) 

From  P4.2  we  get  CLS'(f-|)  = V.cls,  but  C4.5 
guarantees  that  CLS(f-|)  ± V.cls. 

E5  (destroy  file  fj. 

In  order  for  CLS'(f)  not  to  be  undefined, 

1 (f  6 f i a C5.1  a C5.2)  must  hold.  In  that  case 

CLS'(f-|)  = CLS(f-j)  and  the  axiom  is  satisfied  trivially. 
E7  (classification  of  jf  is  raised  to  £). 

There  are  two  possible  outcomes  for  f's  classifica- 
tion. 

i)  ,(f1  = f a C7.1  a C7.2  a C7.3) . 

CLS'(f-j)  = CLS(f-|)  from  P7.2  and  the  axiom  holds 
trivially. 
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ii)  f1  = f a C7.1 a C7.2  a C7.3. 

From  P7.2  we  know  CLS'  (f^)  = Z.  But  from  C7.3, 
CLS(f i ) _^  C.  Thus  CLS(f-j)  < CLS  (f-j). 

Case  4.  All  other  events. 

Property  Px.2  assures  us  that  CLS' (f-j)  = CLS(f-|)  and 
hence  the  axiom  is  satisfied  trivially. 

A2.14  For  all  m-,  e M,  M-CLS  (m-, ) < M-CLS'Oi^). 

The  proofs  are  similar  to  those  for  axiom  A2.13  and  are  omitted 

here. 

A2.15  VceC,  c^c 

A2.16  V c,d,e  e C,  c «d  a d^e  c < e 

Since  the  set  of  security  classifications  remains  unchanged, 
there  is  nothing  to  prove. 


166 


A2.17 


Case  1 


Case  2 


For  all  f i « F » f ■]  <$  f g a f , F' 
f1  < F’. 

E5  (destroy  file  f) 

We  know  f0  e F'  or  equivalently  ST'  (f2)  = USED. 
But  this  can  be  true  only  if  ST(f2)  = USED  and 
“i(f  <5  f2  a C5.1  a C5.2)  by  P5.1.  However 
this  implies  -»(f  6 f-j  a C5.1  a C5.2)  since 
if  — »(f  6 f2)  then  — » (f  6 f-j)  due  to  the  tran- 
sitivity of  the  "6"  relation  on  the  set  of  files 
But  this  along  with  P5.1  tells  us  that  ST' (f^) 
ST(f1 ) . This  means  ST' (f ] ) = USED;  i.e.  e F 
All  other  events. 

From  Px.l  we  know  ST(f^)  = USED  implies  ST' (f^) 
USED. 
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Appendix  E:  Mappings  and  Proofs 


In  this  appendix,  we  will  establish  the  connection  between  and 
S.,.  First  we  will  present  the  mapping  between  levels  by  showing  what 
the  objects  and  functions  of  correspond  to  in  the  previous  level  of 
specification.  Next  we  will  demonstrate  (for  a representative  sample 
of  operations)  that  the  conditions  and  properties  are  sufficient  to 
guarantee  that  the  corresponding  event  in  S3  can  successfully  occur. 

It  should  be  noted  that  there  are  cases  where  the  S3  event  could  occur 
but  the  corresponding  operation  would  fail.  This  is  because  has 
more  restrictions  and  hence  we  will  show  that  the  operation  imp! ies 
the  Sg  event.  Table  E.l  lists  the  correspondences. 


CLS 

CLS 

A CL 

Fav 

TYPE 

ST 

RING 

Fav 

V-CH AR 

Fav 

L-CH AR 

Fav 

p-ctn. 

CLP 

p-type. 

Ep 

atpa/L 

Ep 

childcttt 

Ep 

attcA- -attached 

oc 

via.o-cUta.chzd 

Y 

attached 

Ep 

map 

Ep 

p- zntayno 

Ep 

baanch* 

6 

p (process) 

e (executor) 

Table  E.l  Mapping  from  to  S3 
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Since  we  have  given  the  specifications  in  terms  of  functions  and  the 
values  they  return,  we  will  continue  to  do  so.  However  it  should  be 
remembered  that  these  functions  correspond  to  values  in  repositories 
and  we  are  in  actuality  presenting  a mapping  between  repositories  with 
one  exception.  The  status  of  a file  (whether  it  exists  or  not)  is  a 
physical  property  and  there  is  no  actual  repository  for  each  non-existant 
file  to  specifically  say  that  it  doesn't  exist.  We  assume  that  the 
system  has  some  way  of  knowing  that  a file  exists  and  returns  UNUSED 
when  the  status  of  some  non-existant  file  Is  requested. 

Also,  several  functions  in  may  map  to  a single  function  in 
S3.  For  example,  "AcZ",  "Ring",  "d-dvui"  and  "1-chaA"  all  correspond 
to  the  S3  function,  "Fav".  Thus  if  in  some  S3  event,  "Fav"  remained 
unchanged,  we  would  have  to  show  that  all  of  the  functions  in  S^  which 
were  just  mentioned  also  are  unchanged. 

An  interesting  mapping  concerns  the  tree-structure  of  the  file 
system.  In  S3,  the  "dominates"  relation  (6)  is  shown  to  obey  axioms 
A2.5,  A2.6,  A2.7  and  A2.8.  These  four  axioms  guarantee  that  the  struc- 
ture of  the  file  system  is  a tree*.  In  S4,  we  have  a function  called 
"branch"  which  when  given  some  integer  i,  returns  the  ith  offspring  of 
the  specified  file.  Now  we  say  that: 

f 6 g iff  g = f (g  is  the  same  as  f) 

OR  3 n s.t  g = branch  (f,n)  (n  e N) 

(g  is  one  of  f's  offspring) 

OR  g = fi  and  f = f 3 and  3 ni »n2» • • • >ni 

and  j f ^ , f ...  f ^ s.t. 

f2  = branch  (f 3 ,n-| ) 
f3  = branch  (fg^) 

♦Actually,  the  structure  is  a forest,  however  the  distinction  is  unimportant. 
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f.j_1  = branch  (f-j_2  ni-2^ 
g = branch  (f-j.-j  n^) 

In  other  words  "bAanch"  can  be  thought  of  as  the  "immediate  offspring" 
relation  and  6 is  the  transitive  reflexive  closure  of  that  relation. 
Note  that  substitution  and  composition  can  be  used  with  the  "branch" 
function  so  that: 

f3  = branch  (f 2 » n2 ^ = branch  ( branch  { f -|  >n-| ) ^2) 
and 

f.j  = bAanc.k  (btanch(. . . . (fyuMic/aCfpn-. ) ^2) . . . . )n1-_-| ) 

For  shorthand  we  will  say: 

f.j  = branch1  (f ■)  ,N)  where  N is  the  sequence  <n1  ,n2» . .n^>.  Fur- 
ther, we  define  the  transitive  reflexive  closure  nn  branch: 

f.j  £ bAandi  (f-j  ) iff  f]=f^  and  N = < >,  or  N e N1  and 

f^  = branch.1  (fpN)  for  some  i > 0.  In  the  proofs  to  follow  we  will 

•£> 

assume  that  f 6 g g e bAanc.h  (f)  and  will  show  that  f 6'  g > 
g e branch*' (f)  that  is  the  equivalence  will  exist  after  each  opera- 
tion. One  additional  point  " branch " is  only  defined  on  files  which 
are  in  use. 

Finally,  we  can  talk  about  information  which  the  process  has. 

As  was  detailed  earlier  in  the  chapter,  each  process  has  information 
about  the  file  system  in  the  PST.  The  information  contained  about  a 
file  in  the  PST  is  considered  accurate  if  the  PST  is  attached  to  the 
file.  One  of  the  things  we  must  show  is  that  information  in  the  PST 
agrees  with  actuality.  Again,  we  assume  correctness  before  the  opera- 
tion takes  place  (if  the  file  is  attached)  and  show  that  the  PST  is 
correct  after  the  operation  is  complete. 
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Show  that  S4  operation  #3,  GETACCESS  (view) 
for  F 

implies  Sg-El  e becomes  view-connected  to  file  f. 

S4-C3.3  TYPE(f)  e (DATASEGMENT,  DIRECTORY} 

53—  Cl • 1 ST(f)  * USED 

The  "TYPE"  function  in  S4  corresponds  to  the  "ST"  or  "status"  function 
in  Sg.  Since  TYPE  returns  a value  different  from  "UNUSED"  it  corresponds 
tc  the  "USED"  value  for  "ST" 

54- P3.12=*CLS(f)  <P-cIa[ p)<=* 

Sg-Cl.2  CLS(f)  < CLR(e) 

The  CLS  function  in  S4  corresponds  to  the  CLS  function  in  Sg,  p-cZn 
corresponds  to  CLP  and  executor  e corresponds  to  process  p.  Note  that 
an  S4  property  is  used  here  to  guarantee  an  Sg  pre-condition.  The  rea- 
son is  that  "GETACCESS"  is  more  general  than  "view-connect"  since  it 
also  corresponds  to  "alter-connect".  However  in  order  to  get  view 
access  the  above  property  must  be  true  and  it  is  in  essence  a condition. 
S4-C3.1  \)lm-attached{ D)  ^ 

Sg— Cl .3  e v d 

In  the  mapping,  the  function  "vtm- attached"  corresponds  to  the  "can- 
vt&v"  relation  (v).  Also,  D maps  to  d. 

S4-P3.3  Vfr  TYPE'  ( f 1 ) * TVPfc(f.j)  4=$ 

Sg— P 1.1  Vf  1 , ST'  ( f 1 ) = ST(f-| ) 

Since  TYPE  corresponds  to  ST,  we  show  that  both  are  unchanged. 

S4-P3.1  Vf  , CLS'  (f^  = CLS  (f-, ) 

Sg-Pl.2  Vf  1 , CLS'(f-])  = CLS(f^) 
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Again,  both  sides  of  the  mapping  are  unchanged. 


P3.2 


Vf,  ACL'  (f-i ) = AC L ( f i ) 


P3.4 


P3.5 


< 


RING'  (f] ) * RINGJf^  l 

V-CHAR' (f,)  = P-CHAR (f t ) 


P3.6 


L-CHAR'(fn)  = L-CHAR(f, ) 


/ 


S3-P1.3  Vf-, , Faur  (f-, ) = Fau  (f-| ) 

Here,  all  attributes  which  map  to  "Fav"  are  unchanged  and  hence 

we  merely  show  that  "Fav"  also  is  unchanged. 

S^-P3.15  Vf i , Vn.j , bAanc. A' (f-j  .n^ ) = bAancA(fj  jn^ ) 

This  says  that  all  "bAanch"  functions  are  unchanged.  But  we  also  know 

that  any  set  of  them  (in  particular  those  that  form  a transitive  re- 

1 9 | 

flexive  closure)  are  all  unchanged.  Thus  [Vf-,  ,VNe  N branch/'  ( f ,N) 
= bAanch^  (f-,  »n)]  Vf  bAanak  (f)  = bAanch(  f)t=$g  c bAanch  ‘(f) 


53- PI.5  Ve-| , Vf-,  e-|  «'  f,  e-,  « f, 

For  this  operation  the  "altosi- attached"  function  is  unchanged  which 
agrees  with  the  fact  that  the  "can-alteA"  relation  is  also  unchanged. 

54- P3.I2  VF-, , view- attached'  (F-j ) { — ) (a. view  a [l/IEW-ACCESS 


.)  g e bAanch  (f)  {tttS  S3~P1 .4  Vf,g,  f 6‘  g f 6 g 


S4-P3.I2  — ia. alter  4=}  , alter-attached1  ( F-, ) 


= alteA- attached ( F-,)  v—  > 


(f-|,u)]  a F-,  =F  a C3.1  a C3.2  a C3.3  a [CLS(f-,)  < 
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53- P1  -6  [e-j  v f]  (e-j=e  a f-|=_f  a Cl  .1  a Cl  .2  a Cl  .3)  v e-|  v f] 
Several  mappings  are  used  for  this  step.  First, if  F-|  was  previously 
view-attached  then  the  S3  "can-view"  relation  held,  and  both  still  hold 
after  the  operation/event  takes  place.  The  more  interesting  case  occurs 
when  the  process  did  not  formerly  have  view  access  to  the  file.  Again, 
we  see  that  in  both  S4  and  S3  the  file  in  question  is  the  object  of  the 
operation.  Furthermore  the  process  (implicitly)  and  the  executor  (ex- 
plicitly) are  also  the  object  of  the  operation.  We  showed  above  that 
the  conditions  for  "GETACCESS"  implied  the  conditions  for  "view-connect". 
Thus,  we  have  shown  that  S4-P3.12  implies  S3-PI . 5 . It  should  be  noted 
that  the  implication  goes  only  in  one  direction  since  S4-P3.12  has  the 
additional  restriction  that  user  u (to  whom  the  process  belongs)  is  on 
file  f^'s  access  control  list  (ACL).  The  concept  of  an  ACL  is  unknown 
at  the  S3  level,  anc!  hence  there  is  no  function  to  which  it  maps. 

Many  of  the  properties  of  mailboxes  are  similar  to  those  for  files, 
and  presumably  the  proofs  would  be  similar.  This  paper  does  not  cover 
mailboxes  at  the  S4  level  and  hence  S3  properties  P1.7-P1.10  are  ignored. 

54- P3.8  Vpp  p-ctn'  (p-|)  = p-c^(p1)  v=^ 

S3-Pl.ll  CLR'  (e-j ) = CLR(e1) 

S4  and  S3  guarantee  that  all  processes  and  corresponding  executors 
do  not  change  clearance.  Finally  S4-P3.9  p-typz,  P3.10  alpaA,  P3.ll 
childzrvt,  P3.13  map,  P3.14  p-znfriyno  are  all  made  to  conform  to  their 
respective  values  in  the  file  system.  This  and  the  fact  that  P3.12 
attazhzd( F)  = TRUE  ensure  that  the  values  can  be  taken  as  correct. 

Show  that  S4-#5  CREATE  FILE  £ as  entry  eno  in  d^ with  attributes  V_ 
implies 

S3-E4  executor  e creates  file  f_  in  d^with  attributes 
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S3-P4.1  Vf^F,  ST (f -j ) = 

USED  if  C4.1  a... a C4.6  a f,  = f 

ST  (f-j)  otherwise 

If  the  S4  conditions  are  met,  the  operation  will  occur  and  hence 
S4-P5.15  is  valid.  This  is  sufficient  to  guarantee  that  the  S3  condi- 
tions hold.  The  mappings  are  obvious. 


S4-P5.1  Vf-| , CLS'  (f -| ) = 

Jc^s(V)  if  C5.1  a C5.2  a...a  C5.6  a f1=f)  =$ 

CLS(f^)  otherwise 
S3-P4.2  Vfp  CLS'  (f-, ) = 

(V)  if  C5.1  a ...  C5.S  a f,=f 

^ 1 

CLS(f-|)  otherwise 

Except  for  one  difference  in  the  mapping,  this  proof  is  the  same  as 
the  last  one  \ 


S4-P5.2  Vf  1 eF,  ACL'C^)  = 

J ac£(V)  if  f^f  a C5.1  a.  .. 

^ ACL(f^)  otherwise 
S4-P5.4  Vf-j  eF,  RIWG’  (f-, ) = 

r 

Jbtng(V)  if  f^f  a C5.1  a... 
RIWG(f-j)  otherwise 
S4-P5.5  Vfp  P-CKAR'C^)  = 

J d-cfaVL[\l)  if  f1=f  A C5.1  a ... 
f-CHAR(f^)  otherwise 
S4-P5.6  Vf -j  , L-CHAR'ifj)  = 

I Z-dwA{\l)  if  f1=  f a C5.1  a ... 
, t^CKARCf-j ) otherwise 
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S3-P4.3  Vfp  Fau'  (f-j ) = 

/ 

I V if  fi=f  C4.1  a... 

Fav(f-|)  otherwise 

As  was  pointed  out  before,  Fav  in  S3  corresponds  to  several  attributes 
in  S^.  If  we  also  assume  that  V in  S3  is  appropriately  partitioned, 
then  the  proof  is  similar  to  the  two  preceeding  proofs. 

We  must  now  show  that  S3-P4.4  f-j  6'  f2  iff  f-j  <5  f 2 OR 
(f-|  6 d a f2=f  a C4.1  ...)  OR  (f-|=f2  = f.  A C4.1  ...).  From  S^-P5.15 
we  know:  f2  e branch  (f-j ) iff 

i)  f2  e branch  (f-j)  OR 

ii)  d e bsuinch  (f-j)  (where  N-j  is  the  same  as  N except  for 

the  final  integer  in  the  sequence)  and  f2=f  and  C5.1  etc  OR 

iii ) f -,  = f 2 = f and  C4.1  etc. 

i)  [f2  £ b^ndi* (f-j ) f2  e fvLanc^i*' (f-| )]  ==>[f-j 6 f2=$(f.|  6'  f2) 

a C4 .1  . . . ] 

ii)  [d  £ branch  (f-j)  a f2=f  =£  f2  e branch  '(f-|) 

[^  { d a f2=f  =^(f1  6'  f2)  a C4.1  ...] 

iii)  [f-,  = f2  = f f2  = b/uxndi*(  fpO)]  -=3  [f^f^f 
'f  1 6 1 f2  a C4.1  ...] 

We  can  also  show  that  the  S3  conditions  will  be  satisfied  as  in  previous 

■At 

proofs.  Now  since  [f2  £ branch  (f-|)  £=^i,  ii  or  iii]  we  know 

[f-|  6'  f2t=~>  fi  6 f2  0R  (f  1 6 d a f2=f  a C4.1  ...)  OR  (f-j *f 2=_f  a 

C4.1  ...)] 
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S4~C5.1:  vtw-<vttache.d(S>)  a C5.2  p-typ&(D)  = DIRECT 

=*S3-C4.1  ST(d)  = USED 

The  fact  that  D is  attached  means  that  1)  we  can  assume  D corresponds 
to  d and  2)  we  can  assume  that  p-type  is  correct;  i.e.  it  is  equiva- 
lent to  TYPE(d) . Since  7VPE( d)  is  not  UNUSED,  it  agrees  with  "ST". 
S^-P5.15  Vn«  N.Vd-jeF  s.t.  d-j  f map(D),  bAanch*  (di  ,n)  = bAanch 

(d]  ,n).  Hence  VNe  N*  Vdj e{F-d),  bAanch*'  (d1  ,N)  = 

* 

oAanch  (dpN).  That  is  d is  the  only  file  which  affects 
the  structure  of  the  file  system.  Thus  3 d3  e F and 
jNe  N s.t  f_  = bAanch  1 (d2 »N ) only  if  f_  = bAanch 

(d£ *N ) . But  since  C5.3  type  (f)  = UNUSED  this  is  im- 

* 

possible.  Thus  we  know  Vf-jeF,  VN  if  f = bAanch  r(fpN) 

* 

then  d = bAanch  (fpN-j).  This  proves  S3-C4.3  d 6 f 
a Vf-jeF,  — 1 (d  6'  f-j  a f-|  6'  f a f-|  ^ d) 

S4-C5.3  typc( f)  = UNUSED  =5  S3-C4.4  ST(f)  = UNUSED.  This 

comes  directly  from  the  mapping. 

S4-C5.4  p-c£MD)  1 c£4(V)a  C5.1  <vtta.che.cH D)  = TRUE  =$  S3~C4. 5 
CtS(d)  c6s(V) 

Since  D is  attached,  we  can  accept  p-c£a(d)  as  correct.  The  rest  is 
just  a matter  of  mapping. 


S4-C5.5  type.IV)  e {DATASEGMENT,  DIRECTORY) 

53- C4.6  ^(V)  = USED. 

Since  DATASEGMENT  or  DIRECTORY  indicate  that  a file  is  in  use,  the  above  ar- 
gument specifications  correspond. 

54- P5.3  Vf-jeF,  type.'  (f^  = 


typc{V)  if  C5.1  a C5.2  a ...  a C5.6 

=4 


A f 1 = f 


typc( f-j)  otherwise 
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S4-P5J2  VF-jePST  cditeA.-aitac.ke.dp  ' (Fi ) = atteA-attachedp{?^)  < ■■■■■) 
[S3-P4.5  Ve-jeE,  ^ e F e-j  « f-j  e]  “ f-|] 

Again,  this  Is  merely  a result  of  the  mapping  where  map(F-j)  corresponds 
to  fp  the  processes  correspond  to  executors  and  " aZteA-attazhed."  cor- 
responds to 

[S4-P5.I2  VF-j^PST,  v^ew-aXtac/ied1  (F-j ) = vteio-attazkzd(F^)] 

[S3-P4.6  Ve-jeE,  € F,  e]  y'  f 4=^  e1  y r,] 

This  is  almost  identical  to  the  previous  proof. 

Again,  the  S3  mailbox  properties,  P4.7  - P4.10  are  ignored. 

[S4-P5.8  Vp-jeP,  p-di1  (p-| ) * p-cEA.(p-|)] 

[S3-p4.ll  Ve-jeE,  CLR 1 ( e-j ) * CLR(e-,  )3 
The  mapping  Is  straight  forward. 


S4-P5.9 

VF-jeF, 

p-typz'  (F-j)  = p-typz  (F-j) 

P5.10 

VF-jeF, 

aJLpaA.'  (Fi ) = aJLpaA  (F-j) 

P5.ll 

VF^F, 

zkltdznt' [F = duZdznt  (F-|) 

P5.13 

VFrF, 

map*  (F-| ) = map  (F-j ) 

P5.14 

VFrF, 

p-zntAjyno'  [ F-|)  = p-e.ntA.yno  (F-j) 

S3-P4.I2 

Ve-j  •.  Ep'  (e^  = Ep(e-|). 

Show  that  S4"#6 

DESTROY 

SUBTREE  whose  root  is  £ implies 

S3"E5 

S4-C6.I 

executor  e_  destroys  file  f_  in  directory  £. 
vtew-attackzd(D)  a C6.2  p-typz ( D)  = DIRECT 

S3-C5.I  ST(d)  = USED 

Here,  the  fact  that  D is  attached  allows  us  to  assume  that  "p-typz"  is 
correct;  i.e.  it  agrees  with  TVTE(D).  Again  we  use  the  correspondence 
between  "TypE"  and  "ST"  for  the  proof. 
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S4-C6.1  aZteA-cUtachexl(D)  =7  e ad.  But  due  to  axiom 
A2.3  we  get  S3-C5.2  CLR(e)  1 CLS(d) 

[S4-C6.1  A C6.2  A P6.3  Vf]  e F,  ]N  e N*.  f,  e branch  (map (F  )) 
=^>(TyPE'  (f-| ) = UNDEFINED)]  =3  [S3-P5.I  Vf  ] , f 5 f]  a C5.1  a 
C5.2  =4  ST^)  * DELETED] 

The  satisfaction  of  the  S4  conditions  certainly  guarantees  that  the  S3 

* 

conditions  are  true.  We  have  also  seen  that  "branch  " corresponds  to 
the  "dominates"  relation  (6).  Finally  "T/PE"  corresponds  to  "ST"  and 
the  value  "UNDEFINED"  corresponds  to  "DELETED".  Again  we  have  a case 
where  the  S4  operation  is  more  restrictive  than  the  S3  event.  For  ex- 
ample C6.1,  vlm-attacked(D)  t may  not  happen  to  be  true,  though  e v d. 
However  if  the  S3  conditions  are  false,  the  corresponding  S4  conditions 
will  be  false  and  neither  the  operation  nor  the  event  can  take  place. 

In  other  words,  1 S3  = > — |S4 

S4-P6.1  [Vf-, eF,  3 Ne  f,  e btanch*  (map(F) ) a C6.1  a C6.2  =} 
CLS ' (f ) * UNDEFINED]  =$  [S3-P5.2  Vf^eF,  f i f,  a C5.1 
a C5.2  =}  CLS'  (f  1 ) = UNDEFINED] 

The  obvious  mapping  exists  between  "CLS"  in  S4  and  S3.  The  remainder 
of  the  argument  follows  the  previous  proof.  Again,  the  operation  has 
stronger  restrictions  than  the  event. 

S4-P6.2  (ACL),  P6.4  (RING),  P6.5  (17-CHAR),  P6.6  l L- CHAR) 

[S3-P5.3  Vf-|tF,  f 6 f,  a C5.1  a C5.2  ^Fav'^)  = UNDEFINED] 
Without  belaboring  the  issue,  we  will  just  state  that  all  S4  attributes 
which  correspond  to  S3's  "Fav"  become  undefined  if  conditions  are  met. 
Arguments  for  proof  are  similar  to  the  previous  ones. 
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[S4-P6.15  Vf-jeF,  3 NeN*,  f1=  bunch*  (map (F))  a C6.1  a C6.2 

=^VneN  bunch1  (f^  ,n)  = UNDEFINED]  =9  [f2  = bunch  ' (f-,  ,N] ) 

=>f2  = fcwwcfc*(fi»N1)A  (C6*1  A C6*2)3  (C6.1  a C6.2 

* 

a f1  e bunch  (map(F)ls^  [fj  6'  fg<^  — »(C5. 1 a C5.2  a f^fg] 

In  other  words,  if  one  of  the  conditions  is  false,  then  the  "bunch*" 
relation  will  still  hold.  If  we  assume  C6.1$=^C5.1,  that  is  if  d can 
be  viewed.  It  will  be  view-attached,  then  this  implies  the  f-j  6'  f2  part 
of  E5.  Certainly  If  C6.1  and  C6.2  are  true,  "bunch  " will  be  undefined. 
Furthermore,  C5.1  and  C5.2  will  be  true  and  hence  — i(f-|  <5  f2)  for  f2 
in  the  subtree. 

[S4-P6.12  VF^PST,  aUea- attached’  (F^)  = 

^ UNDEFINED  if  C6.1  a C6.2  a ^Ne  AlVt.  map(F1)  = 

< bunch1  (map(F)  ,N) 

aitea- attacked  (F^)  otherwise 

[S3-P5.5  e-\  a'  f-j  Iff  £j  a f i a — ,(C5.1  a C5.2  a f 6 f^] 

This  proof  closely  follows  the  previous  one. 

S4~P6. 1 2 (aiten- attached) 

S3~P5.6  ( can- v tew) 

This  again  Is  too  similar  to  go  into  more  detail. 

Show  that  S4“#9  Raise  Clearance  to  £ implies 

S3-E16  Executor  t raises  its  own  clearance  to  £ 

S4"C9. 1 p-eJUi  * £ <_  maxcZJi  (p-oACA(p)) 

S3-CI6.I  CLR  (e)  < C < MAXCLR(e) 

The  mappings  are  straightforward.  Some  maximum  is  assumed  to  exist  for 
each  user. 
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S4-P9.1  - P9.6  unchanged  =$ 

S3-PI6.I  - P16.3  "ST",  "CIS",  and  "Fav"  unchanged. 

This  Is  just  a simple  mapping 


S4-P9.15  Vf-jeF,  Vne  N,bumc#i'  (f]  ,n)  = ,n) 

VNeN\  branch.  ^tf-|»N)  = branch.'  (f-|,N)  v=4- 

53- PI6.4  Vfp  f2eF  f1  6 6'  f2. 

Again,  a simple  correspondence. 

54- P9.12  VF-jePST,  (uitZA-cuttackcd1  (Fi ) = cutteA-cuttazkzd  (F-|)a 

(C  < p-zU  (F-j ) ) v — iC9.1] 

==±}  [S3-PI6.6  Vf  1 er,  Ve-|  eE  «'  f-|  4=^  e-j  - f] 
a (C  < CLS(f-| ) v 1 C18.1) 

The  mapping  is  fairly  straightforward,  however  one  must  note  that  "attzA- 
cutta.dn.zd " is  more  restricted  than  "a". 

S4-P16.12  "vZzw-cuttachzd"  unchanged  V 
S3-PI6.6  "can-v-izu)"  unchanged. 

S4"P9.8  Vp-jeP  (the  set  of  processes),  p-cZn'  (p-j)  = 

/ 

£ if  p,  = p a C9.1 
p-ciA(p)  otherwise 

53- Pl6.ll  CLR^)  = ] C if  e-|=e  a C16.1 

Cl.R(ei ) otherwise 

Since  the  conditions  for  S4  and  S3  correspond,  both  will  take  on  a new 
classification  C under  comparable  circumstances. 

54- P9.9,  P9.10,  P9.ll,  P9.13,  P9.14  unchanged 

S3-PI6.I2  Ep  unchanged. 

Again  we  have  a straightforward  mapping. 
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Page  Number  of 


Symbol s Descriptions  Defining  Occurrences 

Sg  The  most  abstract  Security  Structure  11 

R Set  of  information  repositories  14 

A Set  of  agents  14 

C Set  of  security  classes  14 

Classification  function  for  repositories  14 

CVl  Clearance  function  for  agents  14 

_<  Pre-ordering  of  security  classes  14 

4 The  "can  observe"  relation  between  agents 

and  repositories  14 

y The  "can  modify"  relation  between  agents 

and  repositories  14 

A0.1  Reflexivity  Axiom  16 

AO. 2 Transitivity  Axiom  16 

AO. 3 Acquisition  Axiom  16 

AO. 4 Disseminsation  Axiom  16 

t The  "information  can  pass"  relation  between 

repositories  16 

t*  The  "information  can  eventually  pass"  relation  17 

A The  "lower  classification"  relation  on 

repositories  17 

*>en  The  set  of  sensitivity  levels  19 

I 

Cmp  The  set  of  security  compartments  19 

Cg  The  government  Security  Lattice  20 

T0.1  The  basic  security  theorem  20 

Si  A Security  structure  with  files  and  mailboxes  27 
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NOTATION  (continued) 


Symbols 

F 

M 

PF 

°F 

PM 

aM 

6 

A1.1-A1.13 

S2 

E 

S 

T 

V 

ct 

P 

to 

a, 


Descriptions 
The  set  of  files 
The  set  of  mailboxes 

The  "retrieve  information"  relation  for  files 
The  "store  information"  relation  for  files 
The  "receive"  relation  for  mailboxes 
The  "send"  relation  for  mailboxes 
The  "dominate"  relatin  on  the  set  of  files 
The  S-j  axioms 

The  Structure  for  Dynamic  Security 

The  set  of  executors 

The  set  of  states 

The  transition  relation 

The  "can  view"  relation 

The  "can  alter"  relation 

The  "can  block  on"  relation 

The  "can  wake  up"  relation 

Gives  the  set  of  executors,  mailboxes  etc. 
in  each  state 


Page  Number  of 
Defining  Occurrences 


Eq»Wq,a,etc.  The  set  of  executors,  mailboxes  etc.  current 
in  states 

A2.l-A2.ll  The  static  axioms  for  S2 

Eq,Mq,aq  etc. The  sets  of  transient-executors,  transient- 
mailboxes  etc. 


A2.12-A2. 17 
S1 . 5 


The  perpetuates  relation 
The  dynamic  axioms  for  S2 
The  transient-element  structure 


30 

30 

30 

30 

30 

30 

30 

31  - 34 
48 
48 
48 
48 
48 
48 

48 

49 

50 

50 

52 

63 

64 

67  - 68 
68 
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NOTATION  (continued) 


Symbols 

Page  Number  of 

Decriptions  D;fininq  Occurrenws 

S3 

The  Dynamic  Event  Model 

74 

Vf 

set  of  all  possible  file  attributes  values 

75 

Fa.v 

function  which  returns  l/p  set  of  file 
attribute  values 

75 

ct& 

function  to  return  classification  of  a file 
(a  particular  file  attribute  value) 

75 

Fa 

set  of  all  properties  an  executor  might  have 

76 

El ,E2,etc. 

event  numbers 

77 

Cl. 1, Cl. 2, CIO. 1, 
etc. 

pre-conditions  for  the  event 

77 

PI  .1  ,P1 . 2 , PI  0 . 1 

properties  or  effects  of  a successful  event 

77 

function  to  determine  "status"  attribute  from 
set  of  file  attribute  values 

77 

ST 

shorthand  for  Fav  o 

77 

cts,CLS 

return  "classification"  file  attribute 

77 

cJUi,CL  R 

return  "clearance"  of  executor 

77 

M -CIS 

returns  "classification"  attribute  of  mailbox 

78 

Ep 

returns  set  of  executor  properties 

78 

VvSt 

the  "status"  parameter 

81 

V. status 

the  "status"  parameter 

84 

V.cls 

the  "classification"  parameter 

84 

Con 

returns  the  "contents"  property  i.e.  the 
piece  of  information  being  used  by  the  executor 

86 

f .info 

some  information  from  file  f 

86 

PST 

process  segment  table 

110 

CLS 

classification  attribute 

114 
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NOTATION  (continued) 


Symbols 

Page  Number  of 

Descriptions  Defining  Occurrences 

ACL 

access  control  list 

114 

CURLEN 

current  length  of  file 

117 

DTD 

date/time  dumped  attribute 

118 

DTEM 

date/time  entry  modified  attribute 

118 

DTM 

date/time  modified 

118 

DTU 

date/time  used 

119 

IACL 

initial  access  control  list 

119 

INFQCNT 

inferior  quota  count  attribute 

120 

SPUSED 

space  used  attribute 

120 

TACCSW 

terminal  account  switch 

120 

RECUSED 

records  used  attribute 

122 

SAFSW 

safety  switch  attribute 

122 

DID 

secondary  storage  device  identifier  attribute 

122 

UID 

unique  identifier 

123 

PCLR 

process'  clearance 

123 

PUSER 

user  who  owns  process 

123 

ALPAR 

alleged  parent 

124 

PENTRYNO 

entry  number  of  file  with  directory  kept  in  PST 

125 

p-type. 

returns  what  executor  has  listed  as  a file's 
type 

126 

type.,  TYPE 

the  "type"  attribute  of  a file 

126 

branch 

function  which  returns  a particular  offspring 
for  the  specified  file. 

126 

map 

returns  an  internal  pointer  to  a file. 

126 

p-uAeA 

returns  the  name  of  the  user  who  owns  this 
process 

126 
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NOTATION  (continued) 


Symbol s 

Page  Number  of 

Descriptions  Defining  Occurrences 

p-elA 

\ 

returns  a process'  clearance 

129 

alpan. 

t 

returns  the  alleged  parent  entry  in  the  PST 

129 

vizu)- -attach 

boolean  function  which  is  true  if  the  specified 
file  is  presently  view-attached 

131 

aJU.zA-cuttach.zd 

boolean  for  alter-attached 

132 

cuttackzd 

boolean  for  being  attached 

132 

A CL 

returns  access  control  list 

136 

RLNGB 

returns  ring  brackets 

136 

V-CHAR 

returns  the  values  of  all  attributes  logically 
located  with  the  f i T e%  directory 

136 

L-CHAR,l-chaA 

returns  the  value  of  the  local  attributes  - 
those  located  with  the  file  itself 

136,  139 

V.ring.V.type 

V.atbs 

parameters  for  the  operation 

136 

4>ptu>id 

function  whose  value  is  the  amount  of  storage 
space  used. 

139 

mayvA.zu) 

boolean  function  which  is  TRUE  if  a given  user 
may  view  the  specified  file 

141 

maycUlteA 

boolean  function  similar  to  above  but  for  alter 

141 
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